ROSS is an acronym for Rensselaer’s Optimistic Simulation System. It is a parallel discrete-event simulator that executes on multiprocessor systems and/or supercomputers. ROSS is geared for running large-scale simulation models (millions of object models).

This site contains documentation for both ROSS users (aka model developers) and ROSS developers. It also contains an overview and brief history.

If you are currently developing a ROSS model and would like to request a new feature, please create an Issue on Github.

Latest Updates

  • LP and PE Mappings

    Once a model is developed for ROSS, the performance of simulations becomes hugely important. One factor that can play a role is how the LPs are mapped to the physical hardware underneath. LPs that communicate frequently may benefit from being placed within the same MPI process, while LPs that communicate infrequently may be placed on different MPI processes.

  • Release 7.2.0

    This release has some new features:

    • A new default processor clock based on get-time-of-day, which should work on any (and every) architecture (#170)
    • Support for the ARMv7I architecture (#155)
    • A new API for user-defined simulation time (tw_stime) (#159)

  • Versioning and Releases

    In addition to the git branching workflow development model, the ROSS project uses the Semantic Versioning model for version numbers. This helps with reproducibility of experiments detailed in publications and helps users ensure that they are using the correct version of ROSS, especially when using other software that depends on ROSS.

  • Default Clock: Get-Time-of-Day

    With PR #170 there is a new default clock based on the system gettimeofday function. This means that ROSS can function on any architecture, even if a processor-specific system clock is not implemented. More details on the gettimeofday function can be found on the linux man page.

  • Delta Encoding

    Delta encoding provides a solution for models that contain events which are not well suited for using reverse computation or consumes significant amounts of memory (making copy-state approaches infeasible). Delta encoding solves this issue by only computing state change deltas once an event has completed execution. These deltas are then compressed for reduced storage overheads. In addition, delta encoding is done on a per-event basis allowing both reverse computation and delta encoding to be mixed within a single model. Overall, the delta encoding approach provides the benefits of incremental state-saving but without requiring the specific identification of which state elements change. This feature is further described in LaPre et al., 2015.