## MASON-INTEREST-L@LISTSERV.GMU.EDU

 Options: Use Monospaced Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

```Hi all,

Discussing time becomes complicated unless you get the terminology correct.

There are three types of time in simulation:

Virtual (or simulation) time - this is the time represented in the
simulation

Physical (Real time) - this is the time in the real system

Wallclock time - this is the time taken to execute the simualtion.

Lets take an example, ecological simulation.

The virtual time would probably run from 0 to 30 million years and may
be represented by integers, in some suitable increment (for timestepped
simulation), in years perhaps.

The physical time is 20 million BC to 10 million AD and is continuous
(or not - see previous post)

The wallclock time is the time taken to execute the simulation. So if
you're lucky and you have a fast simulation this might run from 3pm to
6pm on 19/01/07.

The other thing to notice is (as Sean says) Mason is a discrete event
simulation. However, the scheduling can make it look like a time-stepped
simulation.

The difference is in the way events are processed. Below is simplified
but should help understanding...

In a time-stepped simulation you have a list of agents....

[a1,a2,...,an]

At each time step (delta t) you call the run/execute method on
a1,...,an. It may be that at this timestep only agents a3,a7 do
something. But you still execute each agent.

A discrete event simulation works differently, you have a schedule
(rather than a list of agents)

[e1,e2,...,en]

where e1 is an "event" with an associated simulation/virtual time stamp
which will typically affect the state of the simulation in some way.

The scheduler basically takes of the event at the front of the list and
executes it. (The event list is order by simulation time, lowest first).
Executing an event may cause a new event to be scheduled in the future.

eg.,
agent has a sense event which indicates an object is at (x,y).
As a consequence of the event being processed a new event is scheduled
in now+t, which will be a move to (x,y) for the agent.

Now, while MASON is discrete event, if you use schedule repeating with
the step method of the agent giving an increment of 1 it basically
operates as a time-stepped simulation.

So what you need to do really is model virtual/simulation time correctly

"Let's say I have 2 locations, home and workplace. The agent travels between
these 2 locations. At a certain time the agent will leave home for work, and
will reach the the workplace at time t. What time should the agent leave
home to be punctual for work?"

Then becomes more about the speed at which the agent can travel, and the
distance of the route (which is presumably not a straight line). If the
route is 20km and the agent drives a car to work at 20km/hour, it will
take one hour.

If you are using time stepped then you need to calculate something like...
1. How far an agent can travel in one step.
2. How many steps it will take.

This may not be totally clear, but Simulation text books will explain

-Mike

Sean Luke wrote:
> Jim, the MASON scheduler, like most such schedulers, maintains two
> measures of temporal progress:
>
>     - the simulation timestamp -- what "time" it is right now in the
> simulation world (not the real world).  That's time().
>     - the number of times the schedule has pulsed.  That's getSteps().
>
> When you schedule an agent on the schedule, it is scheduled to be fired
> at a given timestamp.  The schedule iterates as follows:
>
>     1. Determine the timestamp of the minimum-time-scheduled agent
>     2. Advance the time to that timestamp  (this is what time() returns)
>     3. Extract all agents scheduled for that timestamp
>     4. Sort them by ordering, and shuffle those with the same ordering
> relative to one another
>     5. step() each of them in the order determined by #4
>     6. Increment the number of steps   (this is what getSteps() returns)
>     7. Go to 1
>
> The timestamp can be any real-valued number.  The steps are obviously
> integers (longs).  If you need a measure of "simulation time", you want
> to use time().  But keep in mind that this is a _discrete_event_
> simulator.  If nothing is scheduled for time 3.14159, the schedule will
> never advance to that time -- it'll just skip past it up to the next
> scheduled-for time.
>
> Sean
>
>
> On Jan 9, 2007, at 2:10 PM, Jimmy Ong wrote:
>
>>> schedule.time() will return the current timestamp.
>>
>> Could you kindly elaborate more? I don't quite understand how time()
>> would help in the problem scenario. Rather, how would one use time()
>> in an
>> agent's step method?
>>
>> It seems to me that time() and getSteps() always return the same
>> value, no?
>>