Delta Encoding Tutorial

Delta encoding provides a stop-gap 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. For example, some model events may require a complex nesting of while-loops which cannot be easily or efficiently reversed (LaPre et al., 2014). Delta encoding solves this issue by only computing state change deltas once an event has completed execution. Additionally, we observe that the delta encoding approach provides the benefits of incremental state-saving but without requiring the specific identification of which state elements change. Moreover, because delta encoding is done on a per-event basis reverse computation and delta encoding can be mixed thus enabling modelers to take advantage of reverse computation in events for which it is well suited (e.g., constructive assignments and no complex loops).

For a complete (and probably working) example, see here.

The API is as follows:

tw_snapshot(lp, lp->type->state_sz)
tw_snapshot_delta(lp, lp->type->state_sz)
tw_snapshot_restore(lp, lp->type->state_sz, lp->pe->cur_event->delta_buddy, lp->pe->cur_event->delta_size)

First and foremost, the --buddy_size flag must be set for all ROSS binaries that use delta encoding. A value of 20 will allocate 2^20 or 1 megabyte of space and is usually a good starting point. tw_snapshot() should be called at the top of your event handler while tw_snapshot_delta() should be called before your function returns. Note that it must be called before any function return to properly catch state changes. In your reverse event handler, you must call tw_snapshot_restore() to return the state to its previous values.

Random number generation must also be accounted for. If you make four RNG calls, you must make four RNG uncalls. This can be tracked by using the rng_count member in your message class; see the code linked above for an example.