SST for Newbies



The Structural Simulation Toolkit (SST) is an open-source software framework used for simulating large-scale High Performance Computing (HPC - i.e. Super Computer) systems. It allows parallel simulation of these HPC systems at multiple levels of detail. The simulations can be run on systems as small as a personal workstation on up to large scale multi-node (10,000+) HPC systems. These simulations are intended to assist with designing and evaluating future HPC systems and computer architectures.

SST itself is not a simulator. Instead it is an application and support toolkit that allows multiple disparate/discrete simulators to share data with each other in order to perform very large scale simulations.


The term “node” represents a self contained computer system. Workstations are considered to be a single node. Whereas HPC systems typically consist of many nodes.

SST uses MPI for communication between nodes. MPI creates “ranks” which are a separate computation unit on a node. Note that multiple ranks can be created on a single node, but typically there is one rank per node.

Simple Examples

SST Overview

SST by itself is an application that runs on a computer system. When run, it will read an input input configuration file which then causes SST to dynamically load a set of Dynamic Libraries (called Element Libraries - similar to plugins). These Element Libraries contain a number of internal objects (Components, Modules, etc) that represent the simulators and support objects to perform a simulation. Note that SST can load multiple Element Libraries (simulators) at the same time.

After Loading the Element Libraries, the configuration file will also provide information to SST on how to connect the various objects within an Element Library to other Element Libraries via SST Links (think of a link as a wire or communication channel).

On a multi-rank (multi-node) simulation. SST uses a partitioning algorithm to decide what ranks should load specific Element Libraries (simulators). The first instance of SST will load the configuration file, and then perform the partitioning algorithm. That instance of SST will then use MPI to launch additional instances of SST (on the other ranks) with a partitioned subset of the configuration file. These other instances of SST will then load their appropriate Element Libraries (as defined by the partitioning). Lastly, all Element Libraries across all Ranks will connect (as defined by the configuration) to each other using SST Links.

After all Element Libraries are linked, the simulation will start and run to completion.

There are 3 major items that make up an SST simulation:

If SST is to be run on a multi-node HPC system, it will work with MPI and the HPC system software to run a copy of SST on each required rank/node, instantiate the Element Libraries on specific ranks (called partitioning), and properly create SST links between the Element Libraries. During partitioning, different Element Libraries may be assigned to different ranks depending upon the partitioning algorithm.

After all Element Libraries and loaded and linked, SST will pass operational control to these Libraries allowing them to perform their simulations. During these simulations, the Element Libraries will send and receive event data over the SST links. This will allow the simulations to request and respond to these events as appropriate.

The simulation(s) will continue until a user defined run time limit occurs or all simulations have finished.

At runtime, SST must be provided with an input file that defines what Element Libraries must be loaded and how they are linked, along with any other runtime configuration settings. In a multi-node system, the first executing copy of SST will share the configuration settings with all the other copies of SST along with a partitioning mapping of what nodes are to load what Element Libraries.

The Element Libraries are developed using the C++ programming language and are integrated with the SST Application Programming Interface (API). The Element Libraries are typically designed as one of the following:

SST provides many support services to the Element Libraries via the SST API. These include clocks, events, statistics, partitioning, communication links, etc.

SST Core Application

The SST Core incorporates all the features required to run SST as an application, partition and load the Element Libraries, synchronize multiple copies of SST across ranks/nodes, provide event queues, handle SST links, and provide additional services that the Element Libraries may require.

Additionally, the SST core provides an API that Element Libraries are compiled and linked with to properly interface with SST.

Note: The SST core is a separately compiled C++ application from the Element Libraries (which are compiled dynamic libraries).

Python Script (Input File)

The SST input file is written using the Python programming language with extensions specific to SST.

Element Libraries

An SST Element Library is a compiled C++ library (Linux .so or Mac OSX .dylib) that is dynamically loaded and linked at runtime by the SST Application.

Each Element Library is comprised of one or more of the following functional objects:

At the top level of every Element Library there is a static C++ ElementLibraryInfo structure that identifies the information on all the functional objects. This structure is used at runtime by the SST Core to assist with loading of Element Libraries.

The majority of Element Libraries will contain one or more Components. However Element Libraries can be developed to provide specific support features and may contain no Components.


Components can be regarded as the main code of a simulator (This code may be an actual simulator or a wrapper over a 3rd party simulator).

More than one Component can exist within a single Element Library, and the majority of Element Libraries contain one or more components.

An example would be a Memory Simulation Element Library containing components for:

Each of these models are separate discrete simulators all contained within a single Element Library. The separate components could be “wired” together using SST Links to perform a simple simulation of a computer system.


A grouping of support functions that can be instantiated by Components. Can be thought of as “plug-in” support code for Components.

Sub-Components have access to most of the SST API features provided to Components.

A Component that instantiates a Sub-Component may be in the same or different Element Library from the Sub-Component.

An example would be a router module that provides a query software access to a


Very similar to Sub-Components however does not have access to the support features of Components. A much lighter weight implementation





Ports - (Only on Components) The a listing of the connection points for SST Links on a Component. Also identifies what type of Events are supported by this port.


Support Systems


Clocks & Events

Single Node vs Multinode runs


Supported Platforms



Existing Simulators that work with SST

Each release of SST comes with a number of Sandia developed simulators for Processor, Memory, and Networking. Additionally, many 3rd party developers have integrated simulators that are compatible with SST.

A 3rd party performance simulator can gain several benefits from integration with SST including:

3rd Party simulators

Sandia provided simulators

Zoltan - Metis - GLPK -