We've been using Mason for some simulations now and discovered a
"feature" which can be very annoying.
It seems that the scheduler is using the random generator provided by
the SimState. Which means that if you have a different amount of
schedulable objects or schedule an object at different intervals this
will influence the randomness of the simulation.
Currently we are using Mason to simulate the behavior of a distributed
application and we have an evaluation algorithm to see if a certain
distribution is ok, or that some servers are overloaded. If servers are
overloaded an optimisation algorithm kicks in and redistributes the
application. (in one step).
We run our evaluation function (through a schedulable object) every 200
steps and in every step a the client behavior is simulated by other
The invocation of the evaluation happens by scheduling the schedulable
every 200 steps. If we now decide to change this interval this affects
the whole simulation as all clients (other steppables) are now
influenced by this.
The same happens if you schedule extra objects which don't use the
randomgenerator itself or don't influence any of the other steppables!.
We saw this behavior when we introduced some new steppables to perform
some extra calculations so certain work wasn't duplicated in other
objects. Seeds which initially had an interesting behavior for our
simulations showed a completely new behavior after these changes.
I don't know if this behavior is really intended or not? But is there a
possible solution for it?
Personally I feel that the scheduler should have it's own
randomgenerator. It won't solve all possible situations, but could
One of the things not solved is that the scheduling of steppables with
different orderings will still differ if you add more steppables with
the same ordering. But this won't influence the actual simulation if
these steppables don't interfere.
I hope I could describe the "issues" we are having sufficiently so they
are clear and would like to hear if this is the intended behavior or if
there is a simple way to remedy this.
Bruno Van Den Bossche
[log in to unmask]