matsim-org/matsim-code-examples

Mode share not changing

FarnooshNm opened this issue · 5 comments

Hi, I have multiple subpopulations in the simulation, each having its own set of scoring parameters. I'm using MATSim 15, and although I'm not getting any errors during the simulation run, mode shares are hardly changing. I tried adjusting the mode-specific constants and the SubtourModeChoice weight in strategy settings, but the problem persists. I appreciate any suggestions regarding what could be causing the issue. Thank you.
BUILT modestats

Here is the config file:
config.txt

From what I have seen on the image, there is mode change happening (quite obvious during the first 3 iterations). So, the most likely case is the initial mode share is already approaching relatively stable. If you really want to see mode change effects, maybe setting the mode constant of one mode (for instance car) to a very high volume (like 999) to see whether more agents will select that mode?

Thank you for your response. I'll try the extreme case to check how things change.
Although the modes change in the first 3 iterations, the change is less than 1 percent for each mode.
We also tried altering the initial plans but got a similar plot for the mode share changes over iterations.

Hello, it appears you are using the SubtourMode choice with default settings.
This means, that only closed subtours (i.e. a chain of consecutive trips that starts and ends at the same coordinate) can be mutated and if a subtour is mutated, all trips of that subtour are mutated at a time.
This can lead to some kind of mode change paralysis like you are describing, depending on how the input plans look like. If the input plans contain a high share of non-closed subtours, only a few trips are eligible to get mutated. Moreover, if a subtour is found to be non-mass-conserving (i.e. a chain-based mode is used in a way that the vehicle appears out of nowhere, eventually), it will neither get mutated. One example for such a subtour would be car - car - pt - car.

In order to check your input plans for open (and closed) subtours/activity-chains, you can run e.g. org.matsim.application.analysis.population.SubTourAnalysis. There is also the class FixSubtourModes that fixes mixed-mode subtours (but it won't help with closing activity-chains).

We have introduced a new behavior of the SubtourModeChoice strategy that allows to mutate non-closed subtours, in order to increase agent's mode choice agility and overcome a part of that paralysis. Let's assume the following activity chain: home - work -home - leisure. With the default parameters, SubtourModeChoice could only mutate the trips between home and work, but not the trip between home and leisure (because the subtour is non-closed - the agent does not return to home). In order to allow SubtourModeChoice to do that, you have to

  1. set the behavior parameter to betweenAllAndFewerConstraints;
  2. set the value for the parameter probaForRandomSingleTripMode to something above zero (and below one -- we recommend 0.5). This allows SubtourModeChoice allows to mutate single trips (instead of entire subtours), as well.

Those settings are only available on the config level since about one year.
The value you put for probaForRandomSingleTripMode will determine the probability for an agent to mutate only one trip instead of mutating an entire subtour. When mutating a single trip only, only non-chain based modes are considered (obviously).
Without this setting, it might be very hard (if not impossible) for agents to get from a subtour that is car - car -car to something like pt - drt - pt. Especially for drt-like transport modes, this is unfortunate, as they are often observed to be 'gap-filling-modes'.

Summarizing,
I recommend you to check your input plans and especially the structure of your activity-chains. If you don't need mode choice to respect mass-conservation (e.g. because you assume autonomous cars or sharing systems etc.), you can use the ChangeSingleTripMode strategy. Otherwise, I recommend setting the above parameters for SubtourModeChoice.

After saying all ov the above, I have to add that running 20 iterations is not enough, in almost all cases where you are investigating mode choice. Rather run a few hundreds of iterations....

Thank you so much for your detailed and thorough explanation.
I reduced the number of iterations to 20 just for testing purposes and to identify the cause of the problem.
We had different coordinates for the starting and ending points of a subtour, resulting from generating random points within a zone. As you mentioned, this could have been the cause of the issue since they would be identified as non-closed subtours. It's now fixed, and I can see more noticeable changes in the mode share.
I'm also going to add the probaForRandomSingleTripMode and behavior parameters, as they can be very helpful.
Thanks again for your help.