Hello Jakob,
Sorry for the delay. I was debugging my simulation.
As you guessed there was a heavy jam in my simulation due to the following issues:
1- lack of enough traffic lights
2- loops in the routes
I solved this issues with 1->netedit and 2->--remove-loops by duarouter. So, no issue anymore here. However, it is still very slow (running the simulation is both gui and terminal is very slow)
Regarding the number of vehicles, I am testing an evacuation scenario and I have to have this much of vehicles, although I reduced the number to 50k (instead of 140k) valid trips to see the performance ( -b 0 -e 1800 -p 0.0128), and it is madly slow. I was wondering if you could kindly have a look at the attached figure and advise.
It seems there is a queue for inserting vehicles into the simulation, as insertion-backlogging vehicles is 1881 (unfortunately I could not find enough explanation about this in Wiki, only available explanation is
here)
, loaded vehicles is 7385 and departed is 1649 and arrived is 0. In my routing file until time 95, the id of vehicle is 3737 which means I should have less or equal than 3737 vehicles s shown below:
<vehicle id="3737" type="pv3510" depart="96.04">
1881+1649 is close to this number, but I cannot understand why loaded vehicles is so high and also why 1881 vehicles have issues to enter to the network (if insertion-backlogging means this)
This option removes the vehicle which I do not want to happen, shall I use --random-depart-offset?, and if I use this how long the possible difference will be?
Many thanks
Mohsem
On Thursday, August 30, 2018, 6:39:57 PM GMT+12, Jakob Erdmann <namdre.sumo@xxxxxxxxx> wrote:
Hello,
1) I don't look at the stackoverflow questions, so I cannot actually tell you how good the response time / answer quality there is. I recommend the mailing list.
2) I'm not quire sure about your setup now. You can load trips direclty into sumo (and will perform initial routing just like one-shot does it.
As far As I understood you used DUAROUTER once to turn the trips into routes and then ran these with sumo.
What I don't understand is why there are ~55k vehicles active in the network after just 2 hours. I would assume that this is a bit too much for Wellingten. I suspect that your network is completely jammed and this is slowing down the simulation.
If you run one-shot.py with default arguments it runs through a list of rerouting-frequencies. The first frequency is -1 which means no rerouting. This could also lead to a very jammed network. However, this would not explain the slow speed at the very start where not that many vehicles have been loaded. Try running the .sumocfg generated by one-shot py with the gui and figure out if something odd is happening.
One thing to look out for is the number of insertion-backlogged vehicles listed in the network parameters (accessible via right-click on the background or with the little green vehicle button at the bottom).
regards,
Jakob