spellcheck

Author: lukaspie

.cspell/custom-dictionary.txt

@@ -11,21 +11,26 @@ NXDL
 # Words related to experimental techniques
 
 # Software
+BASECLASS
 caplog
 cnxvalidate
 dataconverter
 DECTRIS
 electronanalyzer
 ELECTRONANALYZER
 ellipsometry
+GROUPNAME
 infty
 libiconv
 loadgroup
 mainfile
+Metainfo
 MSYS
 nexpy
+nexusformat
 nxdls
 PATHCONV
+pathtovalidate
 posint
 punx
 pynxtools
@@ -34,6 +39,7 @@ xdist
 Zenodo
 
 # examples
+alphabetagamma
 appdefdir
 CSET
 ellips
@@ -61,30 +67,53 @@ xfbaa
 arpes
 ARPES
 Bluesky
+emittance
+flatfield
+fluence
 mbar
+monochromator
+monoclinic
 MPES
 Raman
+setpoint
+xraylens
 
 # Names
+Brockhauser
+Brückner
+Dobener
+Draxl
+Fekete
 Forschungsgemeinschaft
+Ginzburg
+Haraszti
 José
 Kühbach
 Lukas
 lukaspie
+Maier
 Markus
+Márquez
 mkuehbach
 Mozumder
 NFDI
 Pielsticker
+Rettig
+Scheidgen
 Shabih
 Sherjeel
 sherjeelshabih
+tommaso
 
 # other languages
 
-# en-UK which requires to many changes
+# en-UK
+analyser
+oxidising
 
 # misc
+appdef
 appdefs
 hypothes
-speciality
+plottable
+underload

.github/workflows/build_docs.yml

@@ -31,7 +31,9 @@ jobs:
       - name: Check spelling
         uses: streetsidesoftware/cspell-action@v7
         with:
-          files: "docs/**/*.md README.md"
+          files: |
+            docs/**/*.md
+            README.md
           strict: true
           incremental_files_only: false
 

cspell.json

@@ -20,6 +20,5 @@
     "words": [],
     "ignoreWords": [],
     "ignoreRegExpList": ["\\bNX\\w*\\b", "https?://[\\S]+"],
-    "import": [],
     "language": "en-US"
 }

docs/getting-started.md

@@ -59,7 +59,7 @@ No. With the available [plugins](./reference/plugins.md) or community-developed
 
 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.
 
-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..
+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..
 
 !!! info "A note on FAIR data"
 

docs/how-tos/pynxtools/validate-nexus-files-other-tools.md

@@ -29,7 +29,7 @@ In case you are interested in testing these tools, we encourage you to follow th
 
 ## `cnxvalidate`
 
-`cnxvalidate` is the validation tool that the NeXus International Advisory Committee (NIAC) has been devepoling and recommending to external users.
+`cnxvalidate` is the validation tool that the NeXus International Advisory Committee (NIAC) has been developing and recommending to external users.
 
 - [Github Repository](<https://github.com/nexusformat/cnxvalidate>)
 
@@ -147,7 +147,7 @@ Now you can use `cnxvalidate` with the executable called `nxvalidate` to validat
 nxvalidate -l DEFINITIONS FILE
 ```
 
-You can now envoke the validation on the test file:
+You can now invoke the validation on the test file:
 
 === "Source"
     ```console
@@ -514,7 +514,7 @@ After installation, you can evoke the help call from the command line:
     ```
 
 
-You can also envoke the help call for the validation API:
+You can also invoke the help call for the validation API:
 
 === "Source"
     ```console

docs/how-tos/pynxtools/validate-nexus-files.md

@@ -36,7 +36,7 @@ Note that you will need to have `pynxtools` installed in a Python environment. L
 
 ## **`validate_nexus`**
 
-After installation, you can envoke the help call of the `validate_nexus` tool from the command line:
+After installation, you can invoke the help call of the `validate_nexus` tool from the command line:
 
 ```bash exec="on" source="material-block" result="ini"
 validate_nexus --help
@@ -67,7 +67,7 @@ Note that here we are passing the `--ignore-undocumented` flag to the validation
 
 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.
 
-You can envoke the help call of the `read_nexus` tool from the command line:
+You can invoke the help call of the `read_nexus` tool from the command line:
 
 ```bash exec="on" source="material-block" result="ini"
 read_nexus --help
@@ -100,7 +100,7 @@ In the output, several concepts are reported as "NOT IN SCHEMA". These are exact
 
 ### The `-c` option
 
-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:
+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:
 
 ```bash
 read_nexus -f src/pynxtools/data/201805_WSe2_arpes.nxs -c /NXarpes/ENTRY/INSTRUMENT/analyser

docs/learn/nexus/nexus-rules.md

@@ -22,7 +22,7 @@ In general, the names of NeXus group and field items are validated according to
 
 Note that this explicitly also means that it is not allowed to have whitespace (including " ") in NeXus names.
 
-A speciality of NeXus is the possibility to define concept names that are different to the names
+A specialty of NeXus is the possibility to define concept names that are different to the names
 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.
 This matching is based on a combination of the `name` and the `nameType` attributes
 of the concept.

docs/learn/pynxtools/nexus-validation.md

@@ -14,8 +14,8 @@ One of the main advantages of using `pynxtools` is that it comes with its own va
 
 The following use cases are covered by the validation in `pynxtools`:
 
-- **Requiredness**: Warnings are logged if a required group/field/attribute is missing. This is also the case for required concepts within recommended/optional groups.
-- **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.
+- **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.
+- **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.
 - **NeXus fields/attributes**:
     - 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.
     - 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
 
 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.
 
-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).
+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).
 
 ## validate_nexus: Validate existing NeXus/HDF5 files
 
 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).
 
-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.
+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.
 
 ## read_nexus: NeXus file reader and debugger