faq 184549398

Config file parameters implications

by harisbal on 2018-02-23 12:14:59

---

Hello MATSim,

I would like to ask the implications of:

a. setting synchronizeOnSimSteps = false (I'm not using within-day replanning)

b. using the FastDijkstra (not sure which implementation of Dijkstra this may be)

Any comment regarding the most influencial parameters to the simulation's execution speed would be welcome. For instance, I know (correct me if I'm wrong) that using transit imposes a large burden on the simulation.

Kind Regards

-Haris

---

Comments: 2

---

Re: Config file parameters implications

by Thibaut Dubernet on 2018-02-27 08:37:21

Dear Haris,

synchronizeOnSimSteps means that, even if the events are processed in a different thread than the QSim, the QSim will not step forward until all events of a time step are processed. This is necessary if you have event handlers that influence the simulation (for instance agents making decisions based on events they listen to). In the normal case, you do not need this: the simulation is allowed to "go faster" than event processing, possibly resulting in slightly faster simulation.

FastDijkstra is an implementation of the regular Dijkstra that is faster, but at the cost of having a bigger memory footprint. There is also a FastAStarLandmarks, that should be even faster. If you do not hit memory problems, I would go for FastAStarLandmarks. Using "Dijkstra" variants do not, in my opinion, make practical sense (A star with landmarks should always be correct and faster).

Public transport indeed imposes a large burden, for two reasons:

• the routing algorithm uses a simple Dijkstra on a time expanded network. This is not the most efficient choice for routing public transport. However, there is a lot of effort currently to implement faster routers. I guess Marcel and Amit could say a bit more about it. We did some experiments with the implementation of Marcel, and the speedup is incredible (20x faster on our Swiss schedule on average).

• You need to simulate all the buses, trams, trains, boats, cable cars, etc. that are in your schedule. With small samples, this ends up representing more vehicles than the agents traveling. There are also various attempts a modules that remove this overhead, essentially "teleporting" agents according to schedule. Again, Marcel could say more about this. This would be faster, but you would miss the effect of buses on congestion (and of congestion on buses)

Our usual approach to control computation time is to play with the sampling rate of the population: go down to 10% or lower for rough experiments, and up to 25% and higher for "production" runs.

---

Re: Config file parameters implications

by harisbal on 2018-03-02 18:32:14

Thank you very much Thibaut!