📄️ Checkpoint and restart
Checkpoint/restart is supported as of SST 15 and partially supported in SST 14. In SST 16, checkpoint files can be restarted with new partitioning and parallelism. Elements are not automatically checkpoint-able. To enable checkpoint/restart, developers must create a function in each element that describes how to serialize the element. A simulation can be checkpointed if all of the elements it uses support checkpoint (i.e., are serializable).
📄️ Debug
This guide discusses SST's built-in interactive debugging capability starting with SST 16.0. The SST debugger enables users to stop a simulation, navigate the element hierarchy, and interrogate internal state using an interactive console. Facilities are provided to trace data and create event triggers that can induce a variety of actions such as breaking into interactive mode or generating a checkpoint.
📄️ Profiling simulation performance
There are a number of ways to gather information about simulation performance from SST itself. The simplest way is to use available command line options. These provide generic information about the simulation as a whole - total memory usage, execution time, etc. For advanced use cases, you can also use ProfileTools to gather more detailed information about specific components or operations within the simulation. The destination for all profiling output can be controlled using the --profiling-output command line option.
📄️ Signal handling
SST handles the SIGINT, SIGTERM, SIGUSR1, and SIGUSR2 signals and also uses SIGALRM to execute actions that occur on a timer. Actions are defined based on the RealTimeAction class. SST provides default actions for each of the signals and allows users to override the default with custom actions for SIGUSR1, SIGUSR2, and SIGALRM.