ROSS doesn't clearly indicate when g_tw_ts_end has been hit about ross HOT 8 CLOSED

As an interim solution in CODES, we've defined our own codes_event_new() wrapper that asserts that the absolute time of the event is < g_tw_ts_end. This isn't appropriate for ROSS since many models deliberately queue events after g_tw_ts_end; we would probably want configurable behavior there (either do nothing, print a warning, or assert).

from ross.

Alternatively, model writers who expect a simulation to run to g_tw_ts_end might be confused if ROSS stops because it ran out of events to process.

The minimal solution might be to just have ROSS display which stopping condition it used as part of its normal output. If it were also indicated as an output argument to tw_run() or tw_end() then model writers could add asserts in main if they wanted to make certain it ended one way or the other.

from ross.

ROSS jumps to g_tw_ts_end when there are no more events to process due to an optimization (ROSS GVTs jump to global minimum time, thus eliminating small, uneventful, time windows). If there are no more events in the system... there can never be any more events in the system.

Would adding clearer documentation surrounding g_tw_ts_end be helpful here?

from ross.

Clearer documentation is always helpful :).

Is it possible for ROSS to determine whether or not events exist past g_tw_ts_end? This knowledge is sufficient for our needs - if an event exceeds g_tw_ts_end, then we know the stopping condition of the simulation, likewise with no events exceeding g_tw_ts_end.

from ross.

ROSS does not schedule events with timestamps beyond g_tw_ts_end (optimization!). Would a warning at this point be useful? It will not show up when the simulation ends, rather, when the event with the bad timestamp is sent.

from ross.

I think a warning is not the right way to thinking about it, as we could have steady state simulations that we want to cut off after a certain time (the protocol simulations Shane has been working on is an example of this). Rather, we simply want to know whether the g_tw_ts_end threshold was passed by an event or not. Preferably this would be printed along with the other summary info ROSS prints out.

from ross.

I am working on this now.

Would the statistic "total events scheduled past end time" be useful? When running in optimistic mode, this number may become somewhat inflated (due to rolled back events sending events past the end time).

from ross.

For my purposes, a binary yes / no would be sufficient, but I understand that the concept may be loose due to rollbacks, so a count is fine.

from ross.