Skip to content

Adapt this Plugin for Your Lab

The nomad-dtu-nanolab-plugin is designed for DTU Nanolab's Materials Discovery group, but it can serve as a template for similar labs performing combinatorial materials synthesis and characterization. This guide explains the key principles for adapting the plugin to your specific needs.

Core Design Principles

When adapting the plugin, maintain these principles to ensure data consistency and reusability:

1. Entities (Physical Items) Should Have Unique IDs

Any persistent physical item in your lab should be an entity with a unique lab identifier:

  • Samples and libraries: Your materials under study
  • Substrates: Base materials with batch tracking
  • Consumables: Targets, gases, chemicals
  • Equipment: Instruments with configurations

Why: Unique IDs enable tracking, referencing, and querying. You can find all measurements on a specific sample or all samples made with a specific target.

Implementation: Extend NOMAD's Entity base class, add lab_id field for your naming convention.

Any process, measurement, or analysis should be an activity that explicitly links entities:

  • Synthesis processes: Inputs (substrates, materials) → Outputs (libraries)
  • Sample preparation: Input (parent libraries) → Outputs (child libraries)
  • Measurements: Inputs (samples, instruments) → Results (data)
  • Analysis: Inputs (measurements, processes, libraries) → Outputs (derived data, figures)

Why: Explicit links create provenance chains. NOMAD automatically builds workflow graphs showing how data connects.

Implementation: Extend NOMAD's Process, Measurement, or Analysis base classes, use reference fields to link entities.

Every measurement should reference:

  • What was measured: The library or the sample position
  • How it was measured: The instrument used
  • When it was measured: Datetime stamps (auto-populated)
  • Results: Standardized data structures

Why: Consistent measurement documentation enables cross-technique comparisons, instrument performance tracking, and automated data aggregation.

Implementation: All measurements extend a common BaseMeasurement class with sample and instrument references.

Computational analysis and data processing should reference:

  • Input data sources: Which measurements provide data
  • Analysis method: Notebook, script, or workflow used
  • Parameters: Analysis settings and assumptions
  • Results: Derived quantities, figures, interpretations

Why: Links analysis results back to raw data, enables reproducibility, tracks data processing steps.

Implementation: Extend NOMAD's Analysis base class, reference measurement entries, store analysis artifacts.

What to Keep from DTU Plugin

Base Infrastructure

The plugin's foundation is broadly applicable:

Common Techniques

Many characterization techniques are universal:

These schemas can be used as-is or extended with lab-specific fields.

Jupyter Analysis

The Jupyter Analysis schema provides flexible analysis documentation that works for any lab.

What to Customize for Your Lab

Lab-Specific Synthesis Techniques

Replace or extend the synthesis schemas based on your methods:

  • Keep if you use: Sputtering, Thermal Evaporation, RTP
  • Add if you use: CVD, MBE, solution processing, spin coating, etc.
  • Extend: Add lab-specific parameters to existing processes

Sample Types and Organization

Adapt sample schemas to your workflow:

  • DTU uses: Combinatorial libraries with position-based sampling
  • You might use: Single samples, standard libraries, wafer-scale fabrication
  • Customize: Sample naming conventions, tracking requirements, batch organization

Lab-Specific Techniques

Add schemas for your unique characterization capabilities:

  • Keep: Standard techniques your lab has (XRD, XPS, etc.)
  • Add: Lab-specific or custom-built instruments
  • Extend: Add parameters specific to your instrument configurations

Instrument Definitions

Define your specific equipment:

  • Catalog: Create instrument entries for your lab's equipment
  • Capabilities: Document what each instrument can do
  • Configurations: Track instrument settings and calibrations

Adaptation Workflow

1. Assess Your Needs

Map your lab workflow:

  • What materials do you synthesize? (Define synthesis process schemas and adapt parsers to your files)
  • What measurements do you perform? (Keep/add characterization schemas and adapt parsers to your files)
  • How do you organize samples? (Customize sample schemas)
  • What are your pain points? (Focus customization there)

2. Start Simple

Phase 1 - Use existing schemas:

  • Deploy the plugin as-is
  • Document a few experiments using schemas that fit
  • Identify gaps and friction points
  • Don't customize yet—understand the system first

Phase 2 - Extend existing schemas:

  • Add lab-specific fields to existing schemas
  • Customize naming conventions (lab_id formats)
  • Adjust dropdown options and defaults
  • Keep the entity/activity structure intact

Phase 3 - Add new schemas and parsers:

  • Create schemas for lab-specific processes or measurements
  • Follow the same patterns (extend Entity or Activity)
  • Maintain provenance chains (link inputs and outputs)
  • Adapt the parsers to ingest your lab's files data automatically
  • Test with real data early and often

3. Common Customizations

Add New Process Types

For lab-specific synthesis check-out the nomad-processing plugin for base classes and inspiration.

Extend Measurements

Add lab-specific parameters to standard techniques or adapt them. We adopted the mapping of our XRD from the nomad-measurements plugin.

from nomad_dtu_nanolab_plugin.schema_packages.xrd import DTUXRDMeasurement

class YourLabXRD(DTUXRDMeasurement):
    """XRD with your lab's specific configuration"""

    # Inherits all standard XRD fields
    # Add lab-specific fields
    custom_scan_mode = Quantity(type=str)
    special_detector_config = Quantity(type=str)

4. Testing and Iteration

Test with real data:

  • Document actual experiments, not hypothetical ones
  • Have researchers use the schemas hands-on
  • Collect feedback on what's confusing or cumbersome
  • Iterate rapidly on customizations

Validate provenance chains:

  • Can you trace: "All XRD measurements on sputtered samples"?
  • Can you trace: Sample → synthesis process → materials used?
  • Can you find: All measurements with a specific instrument?

If queries work, your entity/activity structure is correct.

Resources for Plugin Development

Getting Help

Contributing Back

If you create useful extensions or improvements:

  • Consider contributing back to the DTU plugin (if generally applicable)
  • Share your fork/adaptation with the NOMAD community
  • Document your customizations for others
  • Participate in NOMAD plugin development discussions