You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The central idea behind trace replaying is the capacity to compare stuff across multiple traces.
Option -p plot period has a confusing behavior. E.g. -p 1 does not yield an observation point (roughly) every time unit, but closer to an observation per event. Moreover -p 1000 seems to approach a period of 1 observation per time unit, at least late in the simulation. Why 1000? Is the period relative to the total length of the trace?
If the user wants a plot point every time unit, the user should get that, not roughly every time unit. The key difference is that 2 traces will almost never fall on the same float value of time. These should be dumped in alarm time, or at least like KaSim does respecting the plot period.
Usecase: I have a model with a parameter that can be any of m values. I want to compare the giant-component generation by these m values. I simulate each parametrization for n time units with plot period of 1, get m output files each with n values nicely indexed by their n integer time points. Then I switch to ReConKa and now all my connectivity.csv values across parametrizations are not comparable (i.e. the first point is different for every parametrization). With -p 1 I would expect ReConKa to produce a file with n rows, like KaSim does.
The text was updated successfully, but these errors were encountered:
The central idea behind trace replaying is the capacity to compare stuff across multiple traces.
Option
-p plot period
has a confusing behavior. E.g.-p 1
does not yield an observation point (roughly) every time unit, but closer to an observation per event. Moreover-p 1000
seems to approach a period of 1 observation per time unit, at least late in the simulation. Why 1000? Is the period relative to the total length of the trace?If the user wants a plot point every time unit, the user should get that, not roughly every time unit. The key difference is that 2 traces will almost never fall on the same float value of time. These should be dumped in alarm time, or at least like KaSim does respecting the plot period.
Usecase: I have a model with a parameter that can be any of m values. I want to compare the giant-component generation by these m values. I simulate each parametrization for n time units with plot period of 1, get m output files each with n values nicely indexed by their n integer time points. Then I switch to ReConKa and now all my
connectivity.csv
values across parametrizations are not comparable (i.e. the first point is different for every parametrization). With-p 1
I would expect ReConKa to produce a file with n rows, like KaSim does.The text was updated successfully, but these errors were encountered: