Skip to content

Commit

Permalink
Base class templates (#51)
Browse files Browse the repository at this point in the history 
* 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 15624c0

* 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 a15798b 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 nexusformat#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 <[email protected]>
# Conflicts:
#	contributed_definitions/NXaberration.nxdl.xml
#	contributed_definitions/NXaberration_model.nxdl.xml
#	contributed_definitions/NXaberration_model_ceos.nxdl.xml
#	contributed_definitions/NXaberration_model_nion.nxdl.xml
#	contributed_definitions/NXaperture_em.nxdl.xml
#	contributed_definitions/NXapm.nxdl.xml
#	contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml
#	contributed_definitions/NXcg_alpha_complex.nxdl.xml
#	contributed_definitions/NXcg_cylinder_set.nxdl.xml
#	contributed_definitions/NXcg_ellipsoid_set.nxdl.xml
#	contributed_definitions/NXcg_face_list_data_structure.nxdl.xml
#	contributed_definitions/NXcg_geodesic_mesh.nxdl.xml
#	contributed_definitions/NXcg_grid.nxdl.xml
#	contributed_definitions/NXcg_half_edge_data_structure.nxdl.xml
#	contributed_definitions/NXcg_hexahedron_set.nxdl.xml
#	contributed_definitions/NXcg_marching_cubes.nxdl.xml
#	contributed_definitions/NXcg_parallelogram_set.nxdl.xml
#	contributed_definitions/NXcg_point_set.nxdl.xml
#	contributed_definitions/NXcg_polygon_set.nxdl.xml
#	contributed_definitions/NXcg_polyhedron_set.nxdl.xml
#	contributed_definitions/NXcg_polyline_set.nxdl.xml
#	contributed_definitions/NXcg_roi_set.nxdl.xml
#	contributed_definitions/NXcg_sphere_set.nxdl.xml
#	contributed_definitions/NXcg_tetrahedron_set.nxdl.xml
#	contributed_definitions/NXcg_triangle_set.nxdl.xml
#	contributed_definitions/NXcg_triangulated_surface_mesh.nxdl.xml
#	contributed_definitions/NXcg_unit_normal_set.nxdl.xml
#	contributed_definitions/NXchamber.nxdl.xml
#	contributed_definitions/NXcoordinate_system_set.nxdl.xml
#	contributed_definitions/NXcorrector_cs.nxdl.xml
#	contributed_definitions/NXcs_computer.nxdl.xml
#	contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml
#	contributed_definitions/NXcs_io_obj.nxdl.xml
#	contributed_definitions/NXcs_io_sys.nxdl.xml
#	contributed_definitions/NXcs_mm_sys.nxdl.xml
#	contributed_definitions/NXcs_prng.nxdl.xml
#	contributed_definitions/NXcs_profiling.nxdl.xml
#	contributed_definitions/NXcs_profiling_event.nxdl.xml
#	contributed_definitions/NXdeflector.nxdl.xml
#	contributed_definitions/NXebeam_column.nxdl.xml
#	contributed_definitions/NXem.nxdl.xml
#	contributed_definitions/NXem_conventions.nxdl.xml
#	contributed_definitions/NXem_ebsd.nxdl.xml
#	contributed_definitions/NXem_ebsd_crystal_structure_model.nxdl.xml
#	contributed_definitions/NXevent_data_em.nxdl.xml
#	contributed_definitions/NXevent_data_em_set.nxdl.xml
#	contributed_definitions/NXfabrication.nxdl.xml
#	contributed_definitions/NXgraph_edge_set.nxdl.xml
#	contributed_definitions/NXgraph_node_set.nxdl.xml
#	contributed_definitions/NXgraph_root.nxdl.xml
#	contributed_definitions/NXibeam_column.nxdl.xml
#	contributed_definitions/NXimage_set.nxdl.xml
#	contributed_definitions/NXimage_set_em_adf.nxdl.xml
#	contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml
#	contributed_definitions/NXion.nxdl.xml
#	contributed_definitions/NXisocontour.nxdl.xml
#	contributed_definitions/NXlens_em.nxdl.xml
#	contributed_definitions/NXms.nxdl.xml
#	contributed_definitions/NXms_feature_set.nxdl.xml
#	contributed_definitions/NXms_score_results.nxdl.xml
#	contributed_definitions/NXoptical_system_em.nxdl.xml
#	contributed_definitions/NXorientation_set.nxdl.xml
#	contributed_definitions/NXpump.nxdl.xml
#	contributed_definitions/NXrotation_set.nxdl.xml
#	contributed_definitions/NXscanbox_em.nxdl.xml
#	contributed_definitions/NXspectrum_set.nxdl.xml
#	contributed_definitions/NXspectrum_set_em_eels.nxdl.xml
#	contributed_definitions/NXspectrum_set_em_xray.nxdl.xml
#	contributed_definitions/NXstage_lab.nxdl.xml
#	contributed_definitions/nyaml/NXaberration.yaml
#	contributed_definitions/nyaml/NXaberration_model.yaml
#	contributed_definitions/nyaml/NXaberration_model_ceos.yaml
#	contributed_definitions/nyaml/NXaberration_model_nion.yaml
#	contributed_definitions/nyaml/NXaperture_em.yaml
#	contributed_definitions/nyaml/NXapm.yaml
#	contributed_definitions/nyaml/NXapm_paraprobe_results_nanochem.yaml
#	contributed_definitions/nyaml/NXcg_alpha_complex.yaml
#	contributed_definitions/nyaml/NXcg_cylinder_set.yaml
#	contributed_definitions/nyaml/NXcg_ellipsoid_set.yaml
#	contributed_definitions/nyaml/NXcg_face_list_data_structure.yaml
#	contributed_definitions/nyaml/NXcg_geodesic_mesh.yaml
#	contributed_definitions/nyaml/NXcg_grid.yaml
#	contributed_definitions/nyaml/NXcg_half_edge_data_structure.yaml
#	contributed_definitions/nyaml/NXcg_hexahedron_set.yaml
#	contributed_definitions/nyaml/NXcg_marching_cubes.yaml
#	contributed_definitions/nyaml/NXcg_parallelogram_set.yaml
#	contributed_definitions/nyaml/NXcg_point_set.yaml
#	contributed_definitions/nyaml/NXcg_polygon_set.yaml
#	contributed_definitions/nyaml/NXcg_polyhedron_set.yaml
#	contributed_definitions/nyaml/NXcg_polyline_set.yaml
#	contributed_definitions/nyaml/NXcg_roi_set.yaml
#	contributed_definitions/nyaml/NXcg_sphere_set.yaml
#	contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml
#	contributed_definitions/nyaml/NXcg_triangle_set.yaml
#	contributed_definitions/nyaml/NXcg_triangulated_surface_mesh.yaml
#	contributed_definitions/nyaml/NXcg_unit_normal_set.yaml
#	contributed_definitions/nyaml/NXchamber.yaml
#	contributed_definitions/nyaml/NXcoordinate_system_set.yaml
#	contributed_definitions/nyaml/NXcorrector_cs.yaml
#	contributed_definitions/nyaml/NXcs_computer.yaml
#	contributed_definitions/nyaml/NXcs_filter_boolean_mask.yaml
#	contributed_definitions/nyaml/NXcs_io_obj.yaml
#	contributed_definitions/nyaml/NXcs_io_sys.yaml
#	contributed_definitions/nyaml/NXcs_mm_sys.yaml
#	contributed_definitions/nyaml/NXcs_prng.yaml
#	contributed_definitions/nyaml/NXcs_profiling.yaml
#	contributed_definitions/nyaml/NXcs_profiling_event.yaml
#	contributed_definitions/nyaml/NXdeflector.yaml
#	contributed_definitions/nyaml/NXebeam_column.yaml
#	contributed_definitions/nyaml/NXem.yaml
#	contributed_definitions/nyaml/NXem_ebsd.yaml
#	contributed_definitions/nyaml/NXevent_data_em.yaml
#	contributed_definitions/nyaml/NXevent_data_em_set.yaml
#	contributed_definitions/nyaml/NXfabrication.yaml
#	contributed_definitions/nyaml/NXgraph_edge_set.yaml
#	contributed_definitions/nyaml/NXgraph_node_set.yaml
#	contributed_definitions/nyaml/NXgraph_root.yaml
#	contributed_definitions/nyaml/NXibeam_column.yaml
#	contributed_definitions/nyaml/NXimage_set.yaml
#	contributed_definitions/nyaml/NXinteraction_vol_em.yaml
#	contributed_definitions/nyaml/NXion.yaml
#	contributed_definitions/nyaml/NXisocontour.yaml
#	contributed_definitions/nyaml/NXlens_em.yaml
#	contributed_definitions/nyaml/NXms.yaml
#	contributed_definitions/nyaml/NXms_feature_set.yaml
#	contributed_definitions/nyaml/NXms_score_results.yaml
#	contributed_definitions/nyaml/NXoptical_system_em.yaml
#	contributed_definitions/nyaml/NXpump.yaml
#	contributed_definitions/nyaml/NXrotation_set.yaml
#	contributed_definitions/nyaml/NXscanbox_em.yaml
#	contributed_definitions/nyaml/NXspectrum_set.yaml
#	contributed_definitions/nyaml/NXstage_lab.yaml
#	dev_tools/tests/test_nxdl_utils.py
#	manual/source/classes/contributed_definitions/cgms-structure.rst
#	manual/source/classes/contributed_definitions/em-structure.rst
#	manual/source/classes/contributed_definitions/icme-structure.rst
  • Loading branch information
@mkuehbach @lukaspie
mkuehbach authored and lukaspie committed Dec 11, 2024
1 parent 54e0735 commit 0cd4d80
Show file tree
Hide file tree
Showing 65 changed files with 7,504 additions and 633 deletions.
212 changes: 212 additions & 0 deletions contributed_definitions/NXcg_primitive_set.nxdl.xml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,212 @@
<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="nxdlformat.xsl"?>
<!--
# NeXus - Neutron and X-ray Common Data Format
#
# Copyright (C) 2014-2023 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
# License as published by the Free Software Foundation; either
# 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
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# 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
-->
<definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="base" type="group" name="NXcg_primitive_set" extends="NXobject" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
<!--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.
</doc>
<symbol name="d">
<doc>
The dimensionality of the space.
</doc>
</symbol>
<symbol name="c">
<doc>
The cardinality of the set, i.e. the number of members.
</doc>
</symbol>
</symbols>
<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).
</doc>
<!--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-->
<attribute name="depends_on" type="NX_CHAR">
<doc>
Hint to help resolve in which Euclidean coordinate system field values
like center or orientation are defined.
</doc>
</attribute>
<field name="dimensionality" type="NX_POSINT" units="NX_UNITLESS">
<doc>
The dimensionality of the primitive set.
</doc>
<enumeration>
<item value="1"/>
<item value="2"/>
<item value="3"/>
</enumeration>
</field>
<field name="cardinality" type="NX_POSINT" units="NX_UNITLESS">
<doc>
The cardinality of the primitive set.
</doc>
</field>
<field name="identifier_offset" type="NX_INT" units="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.
</doc>
</field>
<field name="identifier" type="NX_INT">
<doc>
Identifier of each member for explicit indexing.
</doc>
<dimensions rank="1">
<dim index="1" value="c"/>
</dimensions>
</field>
<field name="center" type="NX_NUMBER" units="NX_ANY">
<doc>
The center of mass position of each primitive.
</doc>
<dimensions rank="2">
<dim index="1" value="c"/>
<dim index="2" value="d"/>
</dimensions>
</field>
<!--a depends_on to define in which coordinate system-->
<field name="is_center_of_mass" type="NX_BOOLEAN">
<doc>
True if the center is a center of mass.
</doc>
<dimensions rank="1">
<dim index="1" value="c"/>
</dimensions>
</field>
<field name="shape" type="NX_NUMBER" units="NX_LENGTH">
<doc>
A qualitative description of the shape of each primitive.
</doc>
<dimensions rank="2">
<dim index="1" value="c"/>
<dim index="2" value="d"/>
</dimensions>
</field>
<field name="length" type="NX_NUMBER" units="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.
</doc>
<dimensions rank="1">
<dim index="1" value="c"/>
</dimensions>
</field>
<field name="width" type="NX_NUMBER" units="NX_LENGTH">
<doc>
Qualifier often used to describe the length of one characteristic edge
within the coordinate system.
</doc>
<dimensions rank="1">
<dim index="1" value="c"/>
</dimensions>
</field>
<field name="is_closed" type="NX_BOOLEAN">
<doc>
True if primitive is closed such that it has properties like area or volume.
</doc>
<dimensions rank="1">
<dim index="1" value="c"/>
</dimensions>
</field>
<field name="volume" type="NX_NUMBER" units="NX_VOLUME">
<doc>
Volume of each primitive.

Set to NaN if does not apply for primitives for which is_closed is False.
</doc>
<dimensions rank="1">
<dim index="1" value="c"/>
</dimensions>
</field>
<field name="area" type="NX_NUMBER" units="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.
</doc>
<dimensions rank="1">
<dim index="1" value="c"/>
</dimensions>
</field>
<field name="orientation" type="NX_NUMBER" units="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.
</doc>
<dimensions rank="2">
<dim index="1" value="c"/>
<dim index="2" value="d"/>
</dimensions>
</field>
<group name="vertex_normal" type="NXcg_unit_normal_set"/>
<group name="edge_normal" type="NXcg_unit_normal_set"/>
<group name="face_normal" type="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-->
</definition>
69 changes: 69 additions & 0 deletions contributed_definitions/NXcomponent_em.nxdl.xml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="nxdlformat.xsl"?>
<!--
# NeXus - Neutron and X-ray Common Data Format
#
# Copyright (C) 2014-2023 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
# License as published by the Free Software Foundation; either
# 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
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# 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
-->
<!--
`point Electronic GmbH <https://www.pointelectronic.de>`_-->
<definition xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" category="base" type="group" name="NXcomponent_em" extends="NXobject" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd">
<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.
</doc>
<field name="name" type="NX_CHAR">
<doc>
Given name to the component e.g stage, lens C1, etc.
</doc>
</field>
<field name="description" type="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.
</doc>
</field>
<group type="NXfabrication"/>
<group type="NXprogram"/>
<group type="NXtransformations">
<doc>
Collection of axis-based translations and rotations to describe the
location and geometry of the component in the instrument.
</doc>
</group>
</definition>
Loading

0 comments on commit 0cd4d80

Please sign in to comment.