MASON-INTEREST-L Archives

January 2007

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Fri, 19 Jan 2007 14:00:15 +0000
Reply-To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Content-Transfer-Encoding:
7bit
Subject:
From:
Mike Lees <[log in to unmask]>
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed
In-Reply-To:
MIME-Version:
1.0
Comments:
To: MASON Multiagent Simulation Toolkit <[log in to unmask]>
Parts/Attachments:
text/plain (139 lines)
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 
for your simulation.

Your question:
"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 
more about time/scheduling etc.


-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?
>>
>> Please advise.
>> -Jim

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

ATOM RSS1 RSS2