Plugins¶

Plugins allow one to add Python-based functionality to NOMAD without a custom NOMAD image or release. Plugins can be installed at NOMAD start-up time. Therefore, a NOMAD installation or Oasis can be configured with a different custom set of plugins or disable unnecessary plugins.

Note

You might also want to read the how-to guide on plugins

Plugin entry point reference¶

This is a list of the available plugin entry point configuration models.

AppEntryPoint¶

Base model for app plugin entry points.

name	type
id	`str`	Unique identifier corresponding to the entry point name. Automatically set to the plugin entry point name in pyproject.toml.
entry_point_type	`str`	Determines the entry point type. default: `app`
name	`str`	Name of the plugin entry point.
description	`str`	A human readable description of the plugin entry point.
plugin_package	`str`	The plugin package from which this entry points comes from.
app	`App`	The app configuration.

ExampleUploadEntryPoint¶

Base model for example upload plugin entry points.

name	type
id	`str`	Unique identifier corresponding to the entry point name. Automatically set to the plugin entry point name in pyproject.toml.
entry_point_type	`str`	Determines the entry point type. default: `example_upload`
name	`str`	Name of the plugin entry point.
description	`str`	Longer description of the example upload.
plugin_package	`str`	The plugin package from which this entry points comes from.
category	`str`	Category for the example upload.
title	`str`	Title of the example upload.
path	`str`	Path to the example upload contents folder. Should be a path that starts from the package root folder, e.g. 'example_uploads/my_upload'.
url	`str`	URL that points to an online file. If you use this instead of 'path', the file will be downloaded once upon app startup.
local_path	`str`	The final path to use when creating the upload. This field will be automatically generated by the 'load' function and is typically not set manually.

NormalizerEntryPoint¶

Base model for normalizer plugin entry points.

name	type
id	`str`	Unique identifier corresponding to the entry point name. Automatically set to the plugin entry point name in pyproject.toml.
entry_point_type	`str`	Determines the entry point type. default: `normalizer`
name	`str`	Name of the plugin entry point.
description	`str`	A human readable description of the plugin entry point.
plugin_package	`str`	The plugin package from which this entry points comes from.
level	`int`	Integer that determines the execution order of this normalizer. Normalizers are run in order from lowest level to highest level. default: `0`

ParserEntryPoint¶

Base model for parser plugin entry points.

name	type
id	`str`	Unique identifier corresponding to the entry point name. Automatically set to the plugin entry point name in pyproject.toml.
entry_point_type	`str`	Determines the entry point type. default: `parser`
name	`str`	Name of the plugin entry point.
description	`str`	A human readable description of the plugin entry point.
plugin_package	`str`	The plugin package from which this entry points comes from.
level	`int`	Integer that determines the execution order of this parser. Parser with lowest level will attempt to match raw files first. default: `0`
aliases	`List[str]`	List of alternative parser names. default: `[]`
mainfile_contents_re	`str`	A regular expression that is applied the content of a potential mainfile. If this expression is given, the parser is only considered for a file, if the expression matches.
mainfile_name_re	`str`	A regular expression that is applied the name of a potential mainfile. If this expression is given, the parser is only considered for a file, if the expression matches. default: `.*`
mainfile_mime_re	`str`	A regular expression that is applied the mime type of a potential mainfile. If this expression is given, the parser is only considered for a file, if the expression matches. default: `.*`
mainfile_binary_header	`bytes`	Matches a binary file if the given bytes are included in the file.
mainfile_binary_header_re	`bytes`	Matches a binary file if the given binary regular expression bytes matches the file contents.
mainfile_alternative	`int`	If True, the parser only matches a file, if no other file in the same directory matches a parser. default: `False`
mainfile_contents_dict	`dict`	Is used to match structured data files like JSON or HDF5.
supported_compressions	`List[str]`	Files compressed with the given formats (e.g. xz, gz) are uncompressed and matched like normal files. default: `[]`

SchemaPackageEntryPoint¶

Base model for schema package plugin entry points.

name	type
id	`str`	Unique identifier corresponding to the entry point name. Automatically set to the plugin entry point name in pyproject.toml.
entry_point_type	`str`	Specifies the entry point type. default: `schema_package`
name	`str`	Name of the plugin entry point.
description	`str`	A human readable description of the plugin entry point.
plugin_package	`str`	The plugin package from which this entry points comes from.

Default plugin entry points¶

This is a list of the plugin entry points that are activated by default:

example_upload: None (This upload demonstrate the basic use of NOMAD's parsers. For many electronic structure codes (VASP, etc.), NOMAD provides parsers. You simply upload the input and output files of your simulations and NOMAD parsers are extracting all necessary metadata to produce a FAIR dataset. ), None (This example contains a custom NOMAD schema to create an Electronic Lab Notebook (ELN) and a few example data entries that use this schema. The schema demonstrates the basic concepts behind a NOMAD ELN and can be a good starting point to create you own schemas that model FAIR data acquired in your lab. ), None (This upload demonstrates the used of tabular data. In this example we use an xlsx file in combination with a custom schema. The schema describes what the columns in the excel file mean and NOMAD can parse everything accordingly to produce a FAIR dataset. ), None (This notebook will teach you how you can build tailored research data management (RDM) solutions using NOMAD. It uses existing thermally activated delayed fluorescent (TADF) molecule data to teach you how we can use the NOMAD to turn research data into datasets that are FAIR: Findable, Accessible, Interoperable and Reusable. The end-result can be distributed as a NOMAD plugin: a self-contained Python package that can be installed on a NOMAD Oasis. ), None (This upload provides a notebook as a tutorial that demonstrates how to use NOMAD for managing custom data and file types. Based on a simple Countries of the World dataset, it shows how to model the data in a schema, do parsing and normalization, process data, access existing data with NOMAD's API for analysis, and how to add visualization to your data. ), None (This example presents the capabilities of the NOMAD platform to store and standardize ellipsometry data. It shows the generation of a NeXus file according to the NXellipsometry application definition and a successive analysis of a SiO2 on Si Psi/Delta measurement. ), None (This example presents the capabilities of the NOMAD platform to store and standardize multi photoemission spectroscopy (MPES) experimental data. It contains three major examples:

Taking a pre-binned file, here stored in a h5 file, and converting it into the standardized MPES NeXus format. There exists a NeXus application definition for MPES which details the internal structure of such a file.
Binning of raw data (see here for additional resources) into a h5 file and consecutively generating a NeXus file from it.
An analysis example using data in the NeXus format and employing the pyARPES analysis tool to reproduce the main findings of this paper. ), None (This example presents the capabilities of the NOMAD platform to store and standardize XPS data. It shows the generation of a NeXus file according to the NXmpes application definition and a successive analysis of an example data set. ), None (This example is for two types of experiments: Scanning Tunneling Microscopy (STM) and Scanning Tunneling Spectroscopy (STS) from Scanning Probe Microscopy. It can transform the data from files generated by a the nanonis software into the NeXus application definition NXsts. The example contains data files from the two specific nanonis software versions generic 5e and generic 4.5. ), None (This example is for two types of experiments: Scanning Tunneling Microscopy (STM) and Scanning Tunneling Spectroscopy (STS) from Scanning Probe Microscopy. It can transform the data from files generated by a the nanonis software into the NeXus application definition NXsts. The example contains data files from the two specific nanonis software versions generic 5e and generic 4.5. ), None (This example presents the capabilities of the NOMAD platform to store and standardize atom probe data. It shows the generation of a NeXus file according to the NXapm application definition and a successive analysis of an example data set. The example contains a small atom probe dataset from an experiment with a LEAP instrument to get you started and keep the size of your NOMAD installation small. Ones started, we recommend to change the respective input file in the NOMAD Oasis ELN to run the example with your own datasets. ), None (This example presents the capabilities of the NOMAD platform to store and standardize electron microscopy. It shows the generation of a NeXus file according to the NXem application definition. The example contains a small set of electron microscopy datasets to get started and keep the size of your NOMAD installation small. Ones started, we recommend to change the respective input file in the NOMAD Oasis ELN to run the example with your own datasets. ), None (This example shows users how to take data from a Python framework and map it out to a Nexus application definition for IV Temperature measurements, NXiv_temp. We use the Nexus ELN features of Nomad to generate a Nexus file. )

parser: parsers/chemotion, parsers/elabftw