VOLT
Plugins

Plugin System

How VOLT turns node-based workflows and scientific binaries into analysis results.

TL;DR -- In the UI, a plugin is a workflow. Under the hood, that workflow eventually drives one or more scientific binaries from the wider VOLT ecosystem. The outputs are usually MessagePack exposures that VOLT can list, export, and render back into the viewer.

Overview

Plugins are where VOLT's scientific side becomes extensible.

When a team is created and a cluster is connected, a default set of plugins is deployed so analysis can start immediately. Those plugins are built on top of the open-source algorithm repositories maintained in the ecosystem, which means the product-level plugin system and the lower-level scientific code are closely related but not identical.

That distinction helps avoid confusion: the plugin you see in VOLT is the workflow and runtime contract; the repository in plugins/ is usually the underlying scientific implementation.

What a plugin really is

The easiest way to think about a plugin is as a workflow graph with enough structure for VOLT to understand how to execute it safely and how to interpret the results afterward.

Dislocation Analysis workflow

The workflow defines metadata, user-facing arguments, the execution context, iteration behavior, the actual binary or entrypoint to run, and the outputs that should come back into the platform as exposures or exports.

Main node types

Modifier node

This is the descriptive layer: name, version, authoring details, and the basic information the UI needs to present the plugin in a usable way.

Arguments node

Arguments define what the user is allowed to configure before a run starts. Some values are visible and editable in the UI, while others can be hidden and fixed by the plugin author.

That is what lets a plugin feel approachable in the product even when the underlying binary expects a fairly technical CLI.

Context and forEach

These nodes define what the workflow will iterate over. A common pattern is to bind the workflow to trajectory dumps and then process them frame by frame through a forEach step.

This is one reason analysis progress in VOLT is naturally frame-oriented.

Entrypoint

The entrypoint is where the workflow crosses from product logic into execution. It defines the binary or script payload and the argument template used at runtime.

In many of the built-in scientific plugins, that entrypoint ultimately invokes a compiled executable built from one of the repositories in the open-source plugin layer.

Exposure nodes

Exposure nodes tell VOLT which result files matter after execution. They are the bridge between raw plugin output and something the product can present as a result.

An analysis can produce more than one meaningful output, which is why a single run may surface multiple exposures, listings, sub-listings, charts, or 3D artifacts.

Export nodes

Export nodes turn selected outputs into richer visual forms such as atomistic point clouds, meshes, dislocation geometry, or chart images. These exporters are part of the reason plugin results can come back into the viewer instead of staying as detached files.

Why the design is node-based

The node model gives VOLT a lot more flexibility than a fixed plugin ABI would. It separates workflow planning from execution, makes room for hidden or computed arguments, and lets the runtime handle iteration, branching, nested plugin references, and result processing in a structured way.

That is also why the plugin system can evolve without every analysis looking like a one-off integration.

Output model

Most plugin data returns as MessagePack, but the important part is the shape, not just the file extension.

{
  "main_listing": {},
  "sub_listings": {},
  "per-atom-properties": {}
}

The platform uses that structure to build listings, summaries, overlays, and exports. In other words, MessagePack is not just a storage choice. It is part of the contract between scientific code and product experience.

Plugins and the wider ecosystem

The built-in scientific plugins are not isolated projects. They share infrastructure through tools such as CoreToolkit, and some plugin repositories depend on others internally. StructureIdentification, for example, acts both as a user-facing algorithm and as a building block for more advanced analyses.

That layered relationship is one of the reasons VOLT can present plugins cleanly in the UI without flattening the underlying science into a pile of unrelated binaries.

If you want the repository-level picture behind the plugin system, continue with Open Source Ecosystem. If you want to build your own workflow-compatible plugin, see Plugin Development.

On this page