Geoscience Reference
In-Depth Information
which can use it to calculate the performance score of an agent's plan. These events
can also be utilized to extend the simulation, e.g., modeling the state of charge of
the battery in an electric car or updating the capacity of a parking lot.
After their creation by the micro-simulation, events are handed over to the event-
handler module. Modules interested in certain types of events can register with
the event handler. The event handler then processes each event according to the
instructions of the registered modules.
It is clear that the performance of event handling is critical to the performance
of MATSim and its extensions. In the next section, the implementation of the
JDEQSim and the performance improvements for the event handler are described.
9.3
Implementation
9.3.1
JDEQSim
The re-implementation of DEQSim in Java provided the opportunity to rethink and
redesign its code structure. The C CC DEQSim code is used to understand the
internal structure of the DEQSim traffic model but is not used for the implemen-
tation of JDEQSim itself. The design of JDEQSim is influenced by OMNeT CC
(OMNeT CC 2009 ), which is a modular and open-architecture discrete-event
communication network simulator. To a certain extent, many elements used in
JDEQSim are similar to concepts presented by Axhausen ( 1988 ).
The JDEQSim implementation consists of three parts: simulation units, mes-
sages, and a scheduler. Vehicles and links are the basic building blocks of the traffic
simulation and are called simulation units . These simulation units communicate
with each other by exchanging different kinds of messages, which can be thought
of as internal events, which stay inside the traffic simulation. These are different
from the external events, which are forwarded to the event handler by the micro-
simulation. Each message contains a time stamp, e.g., when a vehicle is allowed to
enter the next link or when a car should start a trip. Each newly created message
is sent to the scheduler. The scheduler contains a message priority queue, which
is ordered by message time and message type. At the beginning of the simulation,
the end time of the first activity of each agent is scheduled in the queue. When
the micro-simulation is started, the scheduler fetches the first message and delivers
each message to its intended target simulation unit, where it gets executed, e.g., a car
leaves one road and enters a new one. Often, execution of the instructions written
in a message leads to the creation of new messages, which are then added to the
queue of the scheduler. The processing of the messages also leads to the generation
of external events, which includes the passing of these events to the event handler,
where they are processed further. The scheduler will always only process the first
message in the queue until all of the messages have been processed and the micro-
simulation ends.
Search WWH ::




Custom Search