Geoscience Reference
In-Depth Information
A possible pitfall of using parallel event handling could arise in the following
way: while with nonparallel event handling it is not a problem if different event
handlers access each other's data, this could cause race conditions in the case
of parallel event handling. This means that if no synchronization is used, data
written by one thread could not be visible to another thread and, as such, data
inconsistencies could occur. While the default event handlers are all implemented in
a way that this problem cannot occur, users not familiar with the intricacies involved
could make such a mistake.
Also, the proposed performance improvement - where a distinction between
event handlers is made, whether they produce output for other MATSim modules
or not - adds to the complexity of how event handling is used till now. This means
that there is a trade-off between usability and performance with regards to parallel
event handling which users need to be informed of.
9.5.3
Replanning Modules
Besides the micro-simulation and event handling, replanning is the third module
in MATSim which requires major computational time. Apart from reducing the
computational time of the various modules involved, work that helps to reduce the
number of iterations required to reach a relaxed state is also important. Ongoing
work related to Meister et al. ( 2006 ) where new optimization methods and heuristics
are applied in order to reduce the number of iterations is interesting in this regard.
Another research strand to investigate is by how much the runtime can be
reduced by making more dynamic use of the replanning module than at the moment.
Currently, the probability for applying a replanning strategy in MATSim is fixed at
the beginning of the simulation. For example, in each iteration 10 % of the agents try
to reroute. While systematic research in this regard is limited, experience suggests
that some search dimensions do not need a constant replanning share throughout
the simulation. For example, the share of rerouting could be reduced over time, as
optimal routes are often found within the first 10-20 iterations with a 10 % reroute
share. This could accelerate the overall simulation as the freed up processing power
could be used by other replanning modules.
9.6
Conclusions
This chapter presents to the best of the authors' knowledge the first implementation
of a large-scale traffic simulation in Java while making use of parallel computing.
Several issues discussed in this chapter have been raised for the first time in traffic
simulation literature and might be useful for the implementation of other traffic
simulation models in Java as well.
Search WWH ::




Custom Search