Skip to content

Key Concepts

This page introduces the core concepts behind the Mat3ra platform. Each term links to the relevant reference page for a detailed explanation.

Core Entities

The platform operates around three main entity types:

  • Materials — a combination of chemical elements in a particular geometric arrangement, defined by descriptive properties (e.g. crystal lattice, basis) and having characteristic properties that can be computed (e.g. band gap, formation energy). Both periodic and non-periodic structures are supported.

  • Workflows — define the simulation logic. Each workflow has one or more characteristic properties associated with it. Workflows depend on the simulation engine, the model, and the method (numerical implementation of the model). Workflows consist of subworkflows and individual units.

  • Jobs — containers of workflow and material information that represent a computation. Jobs are organized into projects and can be under any of the possible statuses.

These three concepts are grouped under the general term entities, as they share many features and user interface components.

Entities Relations

Relationships Between Entities

Computational workflows are applied to materials in order to extract a set of desired properties. The diagram below shows the general relationship between entity types. Properties associated with each entity are labeled with P. Properties that are computed as output of a job (also referred to as characteristic properties) are shown in black — P, and have a certain numerical precision inherited from the workflow and job.

Simulation Components

Models, Methods, and Software

Simulations can be performed with any of the available modeling applications, implementing the supported theoretical models and corresponding computational methods.

Example: model and method

Density Functional Theory (DFT) is an example of a model. Its plane-wave pseudopotential formulation is an example of a method.

Travel Analogy

In order to better understand the difference between a model, method, and simulation, consider a travel analogy:

  1. Setting out to travel from San Francisco to New York — the destination is known. By analogy, a specific address in New York is the characteristic property to be obtained.
  2. Choosing to travel by flight, train, car, or ship — by analogy, this corresponds to choosing the model.
  3. Boarding a specific class of aircraft (jet, propeller) or automobile (sedan, SUV) — by analogy, this corresponds to choosing the method.
  4. The plane could take multiple routes with intermediate stops — by analogy, a method can be realized through multiple workflows containing specifically arranged units.

The process of traveling from San Francisco to New York, by this analogy, is the simulation.

A note on simulation engines: just as there are multiple airplane manufacturers, there are many software applications that implement specific models and methods.

Data and Infrastructure

The platform is designed to store and organize simulation data in centralized databases under the conventions of structured representation. A system of queues is in place for scheduling and tracking the allocation of computational resources, offered by the clusters at the core of the overall infrastructure.