Depending on insertion parameters (i.e. high departSpeed) queues are not expected to reach all the way to the start of the lane. Here are some suggestions: - run a set of comparisons with Demand reduced to the point where neither signal plan is causing departDelay - make your insertion edges very long to convert the virtual queues into real queues - read all about insertion and how to visualize and avoid delay: https://sumo.dlr.de/docs/Simulation/VehicleInsertion.html - include departDelay in your comparison (either avgDepartDelay + avgTravelTime or totalDepartDelay + totalTravelTime)
regards, Jakob Am Mo., 14. Feb. 2022 um 23:01 Uhr schrieb Alexandre Hering Coelho < [email protected]>: > Dear Jakob, > > thank you very much for your answer! > I made an experiment with 100 replications storing the values of > totalTraveTime and totalDepartDelay, using the same base demand with a > little randomness, always with the base signal timing, without using > Webster, just to check the effect of the intersection model. The results > show that the ratio totalDepartDelay/totalTraveTime is in average 0.762 > (76.2%) with 0.192 of standard deviation. That would mean that I have > virtual queues? But I have watched some of the simulations using the GUI > and visually the queues by far do not reach the entry points of the model > during the all 3600 seconds of the scenario. > > Regards, > > Alexandre > --- > Prof. Alexandre Hering Coelho, Dr.-Ing. > Departamento de Engenharia Civil > Universidade Federal de Santa Catarina > Florianópolis, Brasil > > On 14 Feb 2022, at 17:46, Jakob Erdmann <[email protected]> wrote: > > Hello, > I would generally expect that modifying cycle times and green split > according to Webster leads to performance improvements compared to > unoptimized fixed plans. > Could it be that your scenario has significant departDelay in some of your > runs? > A likely reason for unexpected performance measures is that one scenario > has much departDelay and (comparatively) less timeLoss (since timeLoss is > only counted after departure) while another scenario that works better, has > less departDelay but more timeLoss. > A simple way to check is by using statistic-output and comparing the sum > of totalTraveTime and totatDepartDelay (for scenarios that have the same > demand input and run to completion). > > regards, > Jakob > > > Am Mo., 14. Feb. 2022 um 21:13 Uhr schrieb Alexandre Hering Coelho < > [email protected]>: > >> Hi. >> >> I modeled a simple 4-legs intersection with traffic lights. With the help >> of Python I gradually increase the demand volumes, with a certain random >> margin. At each iteration initially I set the cycle time equal to 60 >> seconds, the yellow times equal to 3 seconds and the green times equal to >> 27 seconds, I use Webster's method to determine the optimal cycle time and >> the green times and compare performance metrics between the two scenarios >> (edge based, statistics and queues). I'm very intrigued, because most of >> the time the performance is much worse after optimizing the times. Assuming >> that my calculations are correct and that the logic is all correctly >> implemented (I have reviewed everything dozens of times for days), could >> anyone give any clue to the reason for this strange behavior? Or is it >> always expected that performance will be better after applying Webster's >> method, even at microscopic scenarios, and so can only be a problem in my >> implementation? >> >> I've already experimented with different models of car following, with >> different values of reaction time (action-step-length) and with different >> values of lost times (Webster) and nothing helped. >> >> Thank you. >> >> Alexandre >> >> --- >> Prof. Alexandre Hering Coelho, Dr.-Ing. >> Departamento de Engenharia Civil >> Universidade Federal de Santa Catarina >> Florianópolis, Brasil >> >> _______________________________________________ >> sumo-user mailing list >> [email protected] >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user >> > _______________________________________________ > sumo-user mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user > > > _______________________________________________ > sumo-user mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/sumo-user >
_______________________________________________ sumo-user mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
