diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml index 9d76fb6ebf..22e8269696 100644 --- a/applications/NXapm.nxdl.xml +++ b/applications/NXapm.nxdl.xml @@ -361,6 +361,11 @@ + + + The author(s) of that reference. + + diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml index 1ebf12fdb1..7cc6029eef 100644 --- a/applications/NXem.nxdl.xml +++ b/applications/NXem.nxdl.xml @@ -231,7 +231,14 @@ start_time and end_time together. - + + + + The author(s) of that reference. + + + + Collection of serialized resources associated with the experiment. @@ -1680,13 +1687,52 @@ is required to provide such information in this way!--> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - @@ -1739,11 +1785,38 @@ not wish to duplicate all payload data--> - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - diff --git a/applications/nyaml/NXapm.yaml b/applications/nyaml/NXapm.yaml index 400b91a843..e7f856daf4 100644 --- a/applications/nyaml/NXapm.yaml +++ b/applications/nyaml/NXapm.yaml @@ -308,6 +308,10 @@ NXapm(NXobject): citeID(NXcite): exists: ['min', '0', 'max', 'unbounded'] nameType: partial + author(NX_CHAR): + exists: optional + doc: | + The author(s) of that reference. doi(NX_CHAR): noteID(NXnote): exists: ['min', '0', 'max', 'unbounded'] @@ -1531,7 +1535,7 @@ NXapm(NXobject): dim: (n,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7bec46bfcbbb372ad9c37859e21fe81ecdd1e4ca1c8502c0fdcbf71e757f898c +# 2642b118e31af3d0c5cf93a12ba96d32f0458074c69b36c51821bfa5307ef97c # # # # @@ -3516,11 +3637,38 @@ NXem(NXobject): # # # -# -# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# # -# -# # # # diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml index 55dcc79d88..622665993e 100644 --- a/base_classes/NXem_ebsd.nxdl.xml +++ b/base_classes/NXem_ebsd.nxdl.xml @@ -529,34 +529,33 @@ In another example users may have skipped some scan points (not indexed them at all) or used differing numbers of phases for indexing different scan points. - The cumulated of this array decodes how identifier_phase and matching_phase + The cumulated of this array decodes how phase_id and matching_phase 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), - identifier_phase has as many entries as scan points + phase_id has as many entries as scan points and matching_phase has also as many entries as scan points. - + - The array phases_per_scan_point details how the identifier_phase + The array phases_per_scan_point details how the phase_id and the matching_phase arrays have to be interpreted. - For the example with a single phase identifier_phase has trivial + For the example of a single-phase material phase_id has trivial values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). + sufficiently significant with the model for phase1, an instance of :ref:`NXphase`). - When there are multiple phases, it is possible (although not frequently - required) that a pattern matches eventually (not equally well) sufficiently - significant with multiple patterns. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models. Having such field is especially relevant + For the example of multi-phase material, it is possible (although not frequently + required) that a pattern agrees significantly with multiple patterns. Examples are + cases of pseudosymmetry, insufficiently precise and accurate calibrated systems, + or usage of inaccurate phase models. Having such field is especially relevant for recent dictionary- or artificial intelligence-based indexing methods to communicate the results in a model-agnostic way in combination with matching_phase. - Depending on the phases_per_scan_point value, identifier_phase and + Depending on the phases_per_scan_point value, phase_id and matching_phase arrays represent a collection of concatenated tuples. These 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 @@ -568,10 +567,10 @@ - One-dimensional array, pattern by pattern labelling the solutions found. + One-dimensional array, pattern-by-pattern labelling the solutions found. The array phases_per_scan_point has to be specified because it details - how the identifier_phase and the matching_phase arrays are interpreted. - See documentation of identifier_phase for further details. + how the phase_id and the matching_phase arrays are interpreted. + See documentation of phase_id for further details. @@ -610,6 +609,19 @@ Number of scan points in the original mapping. + + + The shape of the polygon or polyhedron that was used for the tiling + respectively tessellation of the region-of-interest into scan points. + + + + + + + + + diff --git a/base_classes/NXphase.nxdl.xml b/base_classes/NXphase.nxdl.xml index 1b2797b910..faecdfce62 100644 --- a/base_classes/NXphase.nxdl.xml +++ b/base_classes/NXphase.nxdl.xml @@ -35,7 +35,7 @@ null-model (no sufficiently significant information available). In other words, the phase_name is n/a aka notIndexed. - The identifier_phase value should match with the integer suffix of the + The phase_id value should match with the integer suffix of the group name which represents that instance in a NeXus/HDF5 file, i.e. if three phases were used e.g. 0, 1, and 2, three instances of :ref:`NXphase` named phase0, phase1, and phase2 should be stored @@ -46,7 +46,7 @@ Given name as an alias for identifying this phase. - If the identifier_phase is 0 and one would like to use + If the phase_id is 0 and one would like to use the field name, the value should be n/a or notIndexed. diff --git a/base_classes/nyaml/NXem_ebsd.yaml b/base_classes/nyaml/NXem_ebsd.yaml index 16039bad8f..00e64bb79e 100644 --- a/base_classes/nyaml/NXem_ebsd.yaml +++ b/base_classes/nyaml/NXem_ebsd.yaml @@ -383,33 +383,32 @@ NXem_ebsd(NXprocess): In another example users may have skipped some scan points (not indexed them at all) or used differing numbers of phases for indexing different scan points. - The cumulated of this array decodes how identifier_phase and matching_phase + The cumulated of this array decodes how phase_id and matching_phase 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), - identifier_phase has as many entries as scan points + phase_id has as many entries as scan points and matching_phase has also as many entries as scan points. dimensions: rank: 1 dim: (n_sc,) - identifier_phase(NX_INT): + phase_id(NX_INT): unit: NX_UNITLESS doc: | - The array phases_per_scan_point details how the identifier_phase + The array phases_per_scan_point details how the phase_id and the matching_phase arrays have to be interpreted. - For the example with a single phase identifier_phase has trivial + For the example of a single-phase material phase_id has trivial values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). + sufficiently significant with the model for phase1, an instance of :ref:`NXphase`). - When there are multiple phases, it is possible (although not frequently - required) that a pattern matches eventually (not equally well) sufficiently - significant with multiple patterns. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models. Having such field is especially relevant + For the example of multi-phase material, it is possible (although not frequently + required) that a pattern agrees significantly with multiple patterns. Examples are + cases of pseudosymmetry, insufficiently precise and accurate calibrated systems, + or usage of inaccurate phase models. Having such field is especially relevant for recent dictionary- or artificial intelligence-based indexing methods to communicate the results in a model-agnostic way in combination with matching_phase. - Depending on the phases_per_scan_point value, identifier_phase and + Depending on the phases_per_scan_point value, phase_id and matching_phase arrays represent a collection of concatenated tuples. These 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 @@ -420,10 +419,10 @@ NXem_ebsd(NXprocess): matching_phase(NX_INT): unit: NX_UNITLESS doc: | - One-dimensional array, pattern by pattern labelling the solutions found. + One-dimensional array, pattern-by-pattern labelling the solutions found. The array phases_per_scan_point has to be specified because it details - how the identifier_phase and the matching_phase arrays are interpreted. - See documentation of identifier_phase for further details. + how the phase_id and the matching_phase arrays are interpreted. + See documentation of phase_id for further details. dimensions: rank: 1 dim: (n_solutions,) @@ -450,6 +449,13 @@ NXem_ebsd(NXprocess): unit: NX_UNITLESS doc: | Number of scan points in the original mapping. + pixel_shape(NX_CHAR): + doc: | + The shape of the polygon or polyhedron that was used for the tiling + respectively tessellation of the region-of-interest into scan points. + enumeration: [square, hexagon, cube, other] + + # use NXcg_grid in the future (NXmicrostructure): roi(NXdata): doc: | @@ -493,7 +499,7 @@ NXem_ebsd(NXprocess): Label for the x axis # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e4d80825f51ecf58aa6b84c18e9d949b54e644e91bf3a7f60ddd2250b6a96dae +# 2fea464c04385d524fe1b66c6df1f111f4d73bff32a2db6db6ac8a7550b792bb # # # # # # diff --git a/base_classes/nyaml/NXphase.yaml b/base_classes/nyaml/NXphase.yaml index 295562909a..1012d981f2 100644 --- a/base_classes/nyaml/NXphase.yaml +++ b/base_classes/nyaml/NXphase.yaml @@ -14,7 +14,7 @@ NXphase(NXobject): null-model (no sufficiently significant information available). In other words, the phase_name is n/a aka notIndexed. - The identifier_phase value should match with the integer suffix of the + The phase_id value should match with the integer suffix of the group name which represents that instance in a NeXus/HDF5 file, i.e. if three phases were used e.g. 0, 1, and 2, three instances of :ref:`NXphase` named phase0, phase1, and phase2 should be stored @@ -23,7 +23,7 @@ NXphase(NXobject): doc: | Given name as an alias for identifying this phase. - If the identifier_phase is 0 and one would like to use + If the phase_id is 0 and one would like to use the field name, the value should be n/a or notIndexed. (NXunit_cell): (NXatom): @@ -33,7 +33,7 @@ NXphase(NXobject): (NXmicrostructure): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cc674989be959932845b2c4f88f6a4a164e554172145b1337f99859d6c51717b +# 2a599a9d3e679914db9687c01a84542bb9273586d50622dbdee9ac1adfe5fca7 # # # Reference to an instance of: - * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) - * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) + * :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. diff --git a/contributed_definitions/NXmicrostructure_feature.nxdl.xml b/contributed_definitions/NXmicrostructure_feature.nxdl.xml index 3af8dbeea6..0a341174c2 100644 --- a/contributed_definitions/NXmicrostructure_feature.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_feature.nxdl.xml @@ -30,8 +30,8 @@ - The chemical composition of this microstructural feature or this set of - features. + The chemical composition of this microstructural feature + or set of such features. diff --git a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml index b4c9f1b38d..59ae193e3d 100644 --- a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml @@ -120,7 +120,7 @@ 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 identifier_phase + Inspect the definition of :ref:`NXphase` and its field phase_id for further details. Details about possible regridding and associated interpolation diff --git a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml index c33566afcc..a9c13a13b3 100644 --- a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + diff --git a/contributed_definitions/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml index 2dbe76ea49..0d795855b6 100644 --- a/contributed_definitions/NXmicrostructure_odf.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -91,6 +91,19 @@ + + + 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. + + + @@ -178,11 +191,6 @@ 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 diff --git a/contributed_definitions/nyaml/NXmicrostructure.yaml b/contributed_definitions/nyaml/NXmicrostructure.yaml index 8b35823e07..cf21791b48 100644 --- a/contributed_definitions/nyaml/NXmicrostructure.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure.yaml @@ -225,9 +225,9 @@ NXmicrostructure(NXobject): doc: | Reference to an instance of: - * :ref:`NXcg_polyline` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) - * :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) - * :ref:`NXcg_polyhedron` or :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) + * :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. number_of_crystals(NX_UINT): @@ -672,7 +672,7 @@ NXmicrostructure(NXobject): dim: (n_qj,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0043e320305db51c18feb24e529294bd74cf4df5daff3ffae0df536873e16c70 +# b9eac6a925d2c340ac26c59737ccb42dfc4d9732586375d489c128057c101359 # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml index 3502889241..ccd87f1553 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_odf.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_odf.yaml @@ -43,6 +43,16 @@ NXmicrostructure_odf(NXprocess): unit: NX_ANGLE doc: | Resolution of the kernel. + characteristics(NXprocess): + doc: | + Group to store descriptors for a rough classification of an ODF. + texture_index(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + 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. # specific values and typical results kth_extrema(NXprocess): @@ -113,12 +123,6 @@ NXmicrostructure_odf(NXprocess): 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. - - # \@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: | @@ -150,7 +154,7 @@ NXmicrostructure_odf(NXprocess): dim: (n_varphi_two,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 243a65e23623a0bc9a66f1041e4358c0618fc1e7d740eb7fdd81edc48865ada1 +# 6114794aa8ae148316c93ba3a4ce3c0e831110d194f032dcf2cc947b2bd4d9d4 # # # # # @@ -331,11 +348,6 @@ NXmicrostructure_odf(NXprocess): # 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