You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/getting-started.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -59,7 +59,7 @@ No. With the available [plugins](./reference/plugins.md) or community-developed
59
59
60
60
NeXus is supported by the research data management platform NOMAD (as a [NOMAD plugin](https://nomad-lab.eu/prod/v1/docs/howto/plugins/plugins.html)). Experimental data files that are compatible with a NeXus application definition can easily be uploaded to NOMAD and translated into the [NOMAD Metainfo](https://nomad-lab.eu/prod/v1/gui/analyze/metainfo/pynxtools) data model using `pynxtools`. Therefore, the data file can be recognized by NOMAD's search system. If you want to learn more about uploading NeXus data to NOMAD, please refer to the [NeXus to NOMAD tutorial](./tutorial/nexus-to-nomad.md) of this documentation.
61
61
62
-
To use the `pynxtools` Python package with NOMAD, simply install it in the same Python environment as the `nomad-lab` package. NOMAD will recognize `pynxtools` as a plugin automatically and offer automatic parsing of `.nxs` files. In addition, NOMAD will automatically transform the NeXus definitions shipped with `pynxtools` into its own datamodel called `Metainfo`. By default, `pynxtools` is already included in the NOMAD [production]https://nomad-lab.eu/prod/v1/gui/ and [staging](https://nomad-lab.eu/prod/v1/staging/gui/) deployments..
62
+
To use the `pynxtools` Python package with NOMAD, simply install it in the same Python environment as the `nomad-lab` package. NOMAD will recognize `pynxtools` as a plugin automatically and offer automatic parsing of `.nxs` files. In addition, NOMAD will automatically transform the NeXus definitions shipped with `pynxtools` into its own data model called `Metainfo`. By default, `pynxtools` is already included in the NOMAD [production]https://nomad-lab.eu/prod/v1/gui/ and [staging](https://nomad-lab.eu/prod/v1/staging/gui/) deployments..
@@ -67,7 +67,7 @@ Note that here we are passing the `--ignore-undocumented` flag to the validation
67
67
68
68
While `validate_nexus` is used as a tool for _validating_ a NeXus file, `read_nexus` is an _annotator_ tools. It outputs a debug log for a given NeXus file by annotating the data and metadata entries with the definitions from the respective NeXus base classes and application definitions to which the file refers to. This can be helpful to extract documentation and understand the concept defined in the NeXus application definition.
69
69
70
-
You can envoke the help call of the `read_nexus` tool from the command line:
70
+
You can invoke the help call of the `read_nexus` tool from the command line:
@@ -100,7 +100,7 @@ In the output, several concepts are reported as "NOT IN SCHEMA". These are exact
100
100
101
101
### The `-c` option
102
102
103
-
Aside from producing the full anotator log for the NeXus file, `read_nexus` can also be used with the `-c` (or `--concept` option). This helps you to find out all instances in the file that correspond to a given concept path. If you want to find all groups in the file that implement the `analyser` group within `/NXarpes/ENTRY/INSTRUMENT`, you can run:
103
+
Aside from producing the full annotator log for the NeXus file, `read_nexus` can also be used with the `-c` (or `--concept` option). This helps you to find out all instances in the file that correspond to a given concept path. If you want to find all groups in the file that implement the `analyser` group within `/NXarpes/ENTRY/INSTRUMENT`, you can run:
Copy file name to clipboardExpand all lines: docs/learn/nexus/nexus-rules.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,7 +22,7 @@ In general, the names of NeXus group and field items are validated according to
22
22
23
23
Note that this explicitly also means that it is not allowed to have whitespace (including " ") in NeXus names.
24
24
25
-
A speciality of NeXus is the possibility to define concept names that are different to the names
25
+
A specialty of NeXus is the possibility to define concept names that are different to the names
26
26
of the actual data instances. In NeXus base classes and application definitions, there are three options for defining how instances must be named to match to the name of a given concept.
27
27
This matching is based on a combination of the `name` and the `nameType` attributes
Copy file name to clipboardExpand all lines: docs/learn/pynxtools/nexus-validation.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,8 +14,8 @@ One of the main advantages of using `pynxtools` is that it comes with its own va
14
14
15
15
The following use cases are covered by the validation in `pynxtools`:
16
16
17
-
-**Requiredness**: Warnings are logged if a required group/field/attribute is missing. This is also the case for required concepts within recommended/optional groups.
18
-
-**Namefitting**: NeXus allows for variable instance names for a given concept through the combination of uppercase notation and the `nameType` attribute (for more information see the [section on NeXus naming rules](../nexus/nexus-rules.md#name-resolution).) In the validation process, the name of any instance data is compared to the defined NeXus concepts. Errors are raised if a group/field uses a name defined for a concept of a different NeXus type (i.e., if a group in the instance data has the same name as a defined field). If a given instance data point cannnot be fit to any concept, a warning is logged as well.
17
+
-**Requirement concepts**: Warnings are logged if a required group/field/attribute is missing. This is also the case for required concepts within recommended/optional groups.
18
+
-**Namefitting**: NeXus allows for variable instance names for a given concept through the combination of uppercase notation and the `nameType` attribute (for more information see the [section on NeXus naming rules](../nexus/nexus-rules.md#name-resolution).) In the validation process, the name of any instance data is compared to the defined NeXus concepts. Errors are raised if a group/field uses a name defined for a concept of a different NeXus type (i.e., if a group in the instance data has the same name as a defined field). If a given instance data point cannot be fit to any concept, a warning is logged as well.
19
19
-**NeXus fields/attributes**:
20
20
- For concepts where an [**enumeration**](https://manual.nexusformat.org/nxdl_desc.html#enumeration) is used, it is checked if the provided value is contained in the enumeration. For _closed_ enumerations, a warning is logged if the provided value does not match any of the enumeration choices. For _open_ enumerations, an info level message is logged in such cases.
21
21
- Values of fields and attributes are checked against the [**NeXus data type**](https://manual.nexusformat.org/nxdl-types.html#index-0) and warnings are logged if a mismatch is detected.
@@ -35,13 +35,13 @@ During [data conversion](dataconverter-and-readers.md) within `pynxtools`, befor
35
35
36
36
It is also possible to define in the data conversion process whether the data shall be [compressed in the HDF5 file](https://docs.hdfgroup.org/archive/support/HDF5/faq/compression.html). Warnings are logged if the given compression strength (which must be between 0 and 9) is incorrect.
37
37
38
-
Since the validation is performed during the conversion, it is possible to automatically correct the data: as a convenience feature, any instance data that produces invalid files (e.g., when an HDF5 field would be named the same as a group in the NeXus defintions) are removed before writing the files. In addition, if a mismatch between the data type of the instance and the concept is detected, for we convert these values silently if possible (e.g., from int to float or from the string representation of bools (`"true"`/`"false"`) to actual booleans).
38
+
Since the validation is performed during the conversion, it is possible to automatically correct the data: as a convenience feature, any instance data that produces invalid files (e.g., when an HDF5 field would be named the same as a group in the NeXus definitions) are removed before writing the files. In addition, if a mismatch between the data type of the instance and the concept is detected, for we convert these values silently if possible (e.g., from int to float or from the string representation of bools (`"true"`/`"false"`) to actual booleans).
While we encourage NeXus users to convert their data using the `pynxtools` data conversion pipeline, we also realize that a lot of NeXus files are created using other applications. For such use cases, `pynxtools` provides a **standalone validator** (called **`validate_nexus`**). This CLI tool can be used to validate _existing_ HDF5 files against the NeXus application definition they claim to be comply with. Read more in the [API documentation](../../reference/cli-api.md#validate_nexus).
43
43
44
-
Validation of existing files is generally more straightforward than validating the `pynxtools` template as the NeXus type (i.e., group/fields/attribtues) of instance data is easily detected from the file structure. Therefore, no additional special rules are applied in `validate_nexus` other than those given above.
44
+
Validation of existing files is generally more straightforward than validating the `pynxtools` template as the NeXus type (i.e., group/fields/attributes) of instance data is easily detected from the file structure. Therefore, no additional special rules are applied in `validate_nexus` other than those given above.
0 commit comments