Scoring of negative activity durations #1595
Comments
|
Upon exploration we have discovered this |
|
The issue that you reference has to do with the "wrap-around" activity, which assumes that the last and first activity of the day are the same, and for that "stitched together" activity assumes the evening arrival time as activity start time, and the morning departure time as activity end time. (Except of the two activities are of different type, in which case "something else" happens, which I would need to look up.). There is a config switch For all other activities, persons need to arrive before they depart, so negative durations cannot happen. Could you please check your setting of |
|
@gac55 maybe just a question for clarity. You mention
Are you seeing this in the |
|
Thank you kindly @kainagel Good to know, I have checked my config - Thanks @JWJoubert . These are in the final experienced plans. Let me give a concrete (but extreme) example. below is the selected plan (featuring very long walks, with a total score of -3726 and then the unselected (but reasonable!) plan (featuring driving, with a total score of -7315). I should caveat that this is an extreme example, with a very long trip, but it is strange how these extreme walks seem to make it through. Our modeParams for context: |
|
Mode params in context: |
|
Are these truly experienced plans? They look rather like "planned" plans. One thing that could happen: Your simulations cuts at least the walk plan short, e.g. if you terminate the mobsim after 30:00:00 hours. There is a "stuck" penalty, but it may not be large enough to overcome the situation you have here. It is defined in The code would allow to override it, but there is no config setting for it. It is also, as the comment says, not totally easy to set it to a useful value. (Also, if in fact both plans are aborted, it will not make a difference.) As a first attempt, I would try to set up a a special agent with exactly the two plans you have given above, no innovation module, random plans choice, mobsimEndTime set to infty (probably have to set it to zero for that), and see if you then get reasonable scores. |
|
Very helpful, thanks @kainagel. The stuck penalty sounds a lot like the theory we considered. I like the idea of turning innovation off, I will try this. Forgive the simple question - how do I distinguish between planned plans and experienced plans in the outputs? The original driving plan may indeed be a plan plan, I had to mine for it in the |
|
There is a setting |
|
Thank you both. You were ahead of the curve @JWJoubert, I thought I knew what you meant ;) I will do some more digging and run some sims over the week - happy weekend! |
|
Thank you both again. We have some new results:
A final query - Why is the experienced plans not the default output? |
|
I wonder if the discrete mode choice implementation would reduce the occurrences of this. Walking trips would be very unlikely to be suggested as an innovation strategy as their estimated utility would be deemed very poor and would, in theory, be unlikely to be ever simulated. |
|
This looks odd. Could you please send (i.e. add here into github):
|
|
What are your thoughts about the difference between the "planned" and "experienced" plans? Our current working assumption is that times and durations can be different due to the difference between expected and simulated travel times. But we also see changes in mode-share, particulalry from PT modes into car, which i was not expecting. |
Thanks Kai. We're trying to re-create in a test case. If that doesn't work we'll anonymise our current simulation and share here. |
|
Thanks. In the end, we don't need the full files. What we would need:
* The "planned" plan of the concerned agent, and the name of the file from where it comes (I just want to make sure that it is the iteration input file).
* The "experienced" plan of the concerned agent.
* All events of that concerned agent. This will _not_ include linkEnter/Leave events since they are linked to the vehicle, but I do not think that they are neede.
|
|
I've not been able to reproduce the above using toy data, but in the process have got a little more familiar with the fact that we have been using planned rather than experienced plans 🤦🏻 We uncovered that the significant difference in mode-share between planned and experienced plans was due to a systematic scaling error causing some buses to get stuck, therefore curtailing some experienced plans using bus (🤦🏻🤦🏻). I think at this point we are seeing less/no weird scoring/choices - presumably because plans are not getting 'stuck' as often. |
Consider an agent who has busy plans and struggles to fulfil their plans. They may end up with plans that feature trips where they end up late to their activity.
In this case they may end up with a negative duration for this activity. There is a
lateArrivalparam for penalising, but what does MATSim do in these extreme cases? We of course want to score these plans badly.We are seeing some strange walking plans scoring better than driving, for very long/complex plans.
The text was updated successfully, but these errors were encountered: