Deactivating built-in TripRouter when using QueueSimulationListeners to provide dynamic re-routing about matsim-code-examples HOT 4 CLOSED

More specifics on my issue: Running a simulation on 3k vertices and 8k links with 15k agents takes only a few seconds to begin, but, running a simulation on 12k vertices and 35k links with 30k agents, and the simulation hangs after calling controler.run() (I gave up after 90 minutes).

I believe the only thing that is in the control flow related to my code after controler.run() are my event handlers and qsim listeners. When I debug these, I don't see them getting called. While hanging, 100% CPU is in use, but plenty of memory is still available (should rule out thrashing?). I wrap controler.run() in a try catch statement, but don't see any evidence of an exception. Is something failing silently?

I know this is suspicious in that it could be on my implementation. I don't think my inputs are too big. Perhaps something about adding an overriding QSim? Happy to provide more details if requested.

from matsim-code-examples.

from matsim-code-examples.

To answer to your initial point: you are right that MATSim will attempt to route all trips that are incomplete (missing route) during the PrepareForSim step.

Your approach with a dummy router is also the option I would use as a first step. I actually see two options:

• let the MATSim Router "teleport" all modes based on crow-fly distance. It will still compute routes, but this will be fast.
  • pros: no code, all from config (look at the output config in section "planCalcRoute" and set the parameters in your input config file for all modes to something similar to what is defined there for "walk"
  • cons: all your plans will have valid (though meaningless) routes. This means that if, for one reason or another, your Mobsim module does not do what it should, your simulation might silently produce non-sense
• implement a dummy "RoutingModule" that simply returns empty legs, and set it as the routing module for all modes. I did not test it, but I think this should work.
  • pros: if there is somehow a problem in you Mobsim code, the mobsim will complain about not getting enough information to do its job, allowing you to catch the problem early
  • cons: a bit more code

An third option would be to store all the information PrepareForSim tries to compute in your input plans.

But as Joschka said, there seems to be another problem in your setup, which is difficult to identify given the information we have.

from matsim-code-examples.

length="0.0" was the issue. After adjusting these to "1.0" I found my experiment runs.

The initial delay due to PrepareForSim routing is only about 30 seconds for my current inputs. This amount of delay is not an issue for me at this point, but if it becomes an issue, I will likely implement a DummyRoutingModule.

Thank you @jfbischoff for your intuition, and @tduberne for your suggestion!

from matsim-code-examples.