abstraction and simulation world view continuum

[kanishka]

I'm new to discrete event simulation, read some overviews and
examples. I've seen a detailed use of event-based simulation

Books typically discuss

event-based - scheduler maintains list of instantaneous state changes,
entities react to these changes. scheduler advances by jumping to
clock from event to event
activity-based (and 3 phase implementation) - scheduler maintains a
list of activities and their duration, entities or the simulator run
these activities and perform changes on the entities and world state.
scheduler advances by jump clock from activity starts and ends.
process-based - scheduler just increments clock and runs each process
for a given entity in a round robin or more random fashion. the
entities update their state and the world state.

also there is the custom systems model for large, intensive
simulations. building a distributed simulation , possibly real time,
to run directly on top of the hardware.

finally, JIST makes reference to a hybrid of the process and custom
systems models. where you model using the process view, but a runtime
code-generator modifies your code to run on a jvm-based custom system
simulator.

so in a multi-agent simulation. you have agents/entities with internal
state and environment for the world state.

-in event-based world view, the scheduler must have knowledge of time
and how to inform entities of time that is relevant to them, as well
as the change/event name occuring at that time.
-activity-based, the scheduler must have detailed knowledge of what
actions an entity can perform and know how to communication execution
of those actions to the entities
-process-based, the scheduler has little knowledge of the entities,
simply telling them to each run for a specified time interval.


process based honors abstraction boundaries between the scheduler/
simulator and the entities/agents best.
event based breaks down the boundary a bit, coupling the scheduler
with the names of events relevant to a given entity/agent
activity based loosens the boundary further, as the scheduler knows
not only the names of the activities, but their duration and possibly
more


most of the multi-agent simulators i've seen take a process view of
the world, wiht the main entry point into an agent being:

run( agent, time ){
     update state...
}

but then this ends up becoming a huge condition clause

run( agent, time) {
    if (time == event1's time)
        start activity1
   else if (time == event2's time)
       start activity2
  ...
}

this seems ugly, what if we let the simulator know more about agent,
like the events it can handle. then the run method goes away, and you
have a bunch of handlers.

simulator-run(){
      event = get-first-event()
      while( event != empty) {
             agent = get-target-agent(event)
             agent.handleEvent(event)
             event =get-next-event()
      }
}

nicer, but a little hard to follow the flow of logic from a series of
events that might be closely related... now what if you allow the
scheduler more knowledge of the agent's actions/activities (their
duration, how to execute them on the agent)

simulator-run(){
      activity = get-first-activity()
      while( activity != empty ){
             agent = get-target-agent(activity)
             method = get-method(activity)
             method(agent)
             activity = get-next-activity()
     }
}

that seems to communicate the flow of control a bit more and allow for
a developing an agent that is more clear in its capabilities,
sacrificing some de-coupling...

if one were to agree that the third model leads to cleaner multi-agent
simulator as well as agent/entities within that simulator, it leads to
some questions:

who runs the activity to completion? does the agent run the activity
until its done, returning the time its aware of, now that the activity
is complete. or does the simulator keep telling the agent to continue
running the activity until signalled to complete it.

in the first case, how does teh simulator handle passing overlapping
activities to the agent...

seems like issues of distributed simulation creep in....

any feedback helpful..hope this mostly makes sense.