what type of DES is SST? - researcherben/structural-simulation-toolkit GitHub Wiki

Pages 3-7 of http://heather.cs.ucdavis.edu/~matloff/SimCourse/PLN/DESimIntro.pdf describes three different paradigms for DES:

• activity-oriented DES: at every time increment the controller queries all queues to see if messages need to be conveyed or actions need to be taken. This is slow and not commonly used.
• event-oriented DES: the controller jumps to the next minimum time-step available in all queues (the "event set"). Example: https://github.com/bkamins/EventSimulation.jl
• process-oriented DES: every queue is a separate thread. Example: SimPy

That's orthogonal to the (next-event vs fixed-increment) time progression described on Wikipedia.

The short answer is that SST is a process/event hybrid. That said, there’s some performance characterization given in the paper for each paradigm, and with respect to that, you probably need to separate SST Core from SST elements/components when thinking about how the simulation works and what the performance implications are. The Core is a process/event hybrid, but individual elements can operate in whatever manner they wish (activity/event/process) and that decision has a big impact on performance.

The detailed answer for the SST Core is that each MPI rank and/or C++ thread has its own event queue and maps some set of components. As a user scales SST from a single thread/rank to multiple, SST moves from completely event-oriented to completely process-oriented (albeit without a global event management thread). At the process-oriented limit, each component maps to its own thread/rank. In practice, scaling out that far isn’t useful, and most simulations end up as a hybrid: multiple components map to each thread/rank and share a single event queue. Within a thread/rank, the queue is managed in an event-oriented manner, skipping ahead to the minimum time of the enqueued event. In contrast to the example given on page 7 though, SST doesn’t have a central event management thread. Instead each pair of threads/ranks synchronizes at an interval determined by the latencies of the links that cut the pair.

The labeling gets a little complex is with respect to individual components and the performance characterizations of the paradigms described in that paper. Nothing prevents an element from waking up at a regular (small) interval and polling a link to determine if an event has arrived and it has work to do. If an element does this, and some do, the simulation will end up behaving exactly like the example the paper gives for an activity-oriented DES, despite the SST Core not using that paradigm. That may mean that it’s not as helpful to characterize SST itself, but instead to characterize the a particular mix of elements used for a simulation. If the elements behave in an event/process-oriented manner, an SST simulation will behave as such, but if they adopt the activity-oriented paradigm, then the simulation will behave that way.