I'm pretty sure that the error is on your end because the parseTime API was changed between sumo versions and this is the expected error when mixing versions. Take a look at https://sumo.dlr.de/docs/TraCI/Interfacing_TraCI_from_Python.html#determine_the_traci_library_being_loaded and substitute 'sumolib' for 'traci' to figure out where the version mix comes from.
Am Do., 27. Aug. 2020 um 17:48 Uhr schrieb Sumo User < [email protected]>: > I downloaded the files from: > https://sumo.dlr.de/docs/Downloads.php#sumo_-_latest_development_version > > But get the original error: > Traceback (most recent call last): > File "detector/edgeDataFromFlow.py", line 124, in <module> > main(get_options()) > File "detector/edgeDataFromFlow.py", line 86, in main > beginM = int(sumolib.miscutils.parseTime(options.begin, 60) / 60) > TypeError: parseTime() takes exactly 1 argument (2 given) > > Could this be a bug or do you think it is a problem on my end? > > On Wed, Aug 26, 2020 at 2:11 AM Jakob Erdmann <[email protected]> > wrote: > >> Hello, >> the error you encountered indicates that you are loading sumo tools from >> different versions which are incompatible regarding their internal API >> (parseTime). Make sure you update all of the sumo tool, the linked >> debugging tip applies also to the other tools: >> https://sumo.dlr.de/docs/TraCI/Interfacing_TraCI_from_Python.html#determine_the_traci_library_being_loaded >> >> Regarding your steps, there may be a misunderstanding. >> In step 1, the route file generated by randomTrips is used as input for >> routeSampler.py rather than as input to edgeDataFromFlow. >> >> Regarding the resulting flows, try running routeSampler with the option >> --optimize full and post the log output. >> >> regards, >> Jakob >> >> >> Am Mi., 26. Aug. 2020 um 00:31 Uhr schrieb Sumo User < >> [email protected]>: >> >>> I used the latest development version and got this error: >>> >>> Traceback (most recent call last): >>> File "detector/edgeDataFromFlow.py", line 124, in <module> >>> main(get_options()) >>> File "detector/edgeDataFromFlow.py", line 86, in main >>> beginM = int(sumolib.miscutils.parseTime(options.begin, 60) / 60) >>> TypeError: parseTime() takes exactly 1 argument (2 given) >>> >>> I opened the code and changed this: >>> >>> beginM = int(sumolib.miscutils.parseTime(options.begin, 60) / 60) >>> >>> intervalM = int(sumolib.miscutils.parseTime(options.interval, 60) / >>> 60) >>> >>> endM = min(int(sumolib.miscutils.parseTime(options.end, 60) / 60), >>> tMax) >>> >>> to this: >>> >>> beginM = int(sumolib.miscutils.parseTime(options.begin) / 60) >>> >>> intervalM = int(sumolib.miscutils.parseTime(options.interval) / 60) >>> >>> endM = min(int(sumolib.miscutils.parseTime(options.end) / 60), tMax) >>> >>> I changed the input interval and end times from minutes to seconds and >>> it ran. But the flow rate did not match my measured data well enough. For >>> example, some exit ramps had a flow of 0 for almost the entire simulation >>> when they should have had cars constantly using them. I'm not too >>> experienced with Python, so I do not know if that edit I made is the reason >>> for the error. >>> >>> I'm not sure where my error is, I wanted to make sure that the following >>> steps made sense: >>> 1) randomTrips.py to get the route file used in edgeDataFromFlow >>> 2) edgeDataFromFlow.py to get the edgeData file >>> 3) routeSampler.py for the route file used in the simulation >>> 4) DFRouter for a validation file and detector file >>> 5) SUMO >>> >>> >>> >>> On Tue, Aug 25, 2020 at 2:06 AM Jakob Erdmann <[email protected]> >>> wrote: >>> >>>> Unfortunately, the 1.6.0 version of routeSampler did not yet handle >>>> data intervals. This is fixed in the latest development version ( >>>> https://sumo.dlr.de/docs/Downloads.php#sumo_-_latest_development_version >>>> ). >>>> However, I would recommend setting the option "--interval 900" to >>>> aggregate the interval data to larger time slices. (or larger depending on >>>> the typical travel time of vehicles within your network). >>>> >>>> Am Mo., 24. Aug. 2020 um 18:34 Uhr schrieb Sumo User < >>>> [email protected]>: >>>> >>>>> Thank you for your response Jakob. >>>>> >>>>> I am working on using routeSampler.py, but have run into a problem >>>>> using edgeDataFromFlow.py. My flow data that was previously used as a >>>>> flow >>>>> input file to DFRouter is three hours of data in 5 minute intervals. When >>>>> I run edgeDataFromFlow, I get an end time of 3600 seconds, but for three >>>>> hours I would expect 10800. I looked in the Python file and did not see >>>>> an >>>>> input for end time, so I was wondering how to change it. >>>>> >>>>> Thank you, >>>>> Alex >>>>> >>>>> On Thu, Aug 20, 2020 at 2:08 PM Jakob Erdmann <[email protected]> >>>>> wrote: >>>>> >>>>>> Unfortunately, DFRouter does not provide additional customization >>>>>> features. Consider using routeSampler.py instead. >>>>>> However, this will only give meaningful changes if the measurement >>>>>> data does not constrain the possible route combinations too strongly. >>>>>> You could also try to define a stronger variation in vehicle speeds >>>>>> by using the speedDev attribute and set sumo option --random in addition >>>>>> to >>>>>> dfrouter option --random. >>>>>> >>>>>> Am Do., 20. Aug. 2020 um 19:04 Uhr schrieb Sumo User < >>>>>> [email protected]>: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I have a set of measured data from a highway on a specific >>>>>>> afternoon. When use DFROUTER to run a simulation, the validation file >>>>>>> matches the measured data in flow and speed well. But after running >>>>>>> many >>>>>>> simulations (>500), I can see that all the validation files are >>>>>>> extremely >>>>>>> similar to each other. What I want is to use my measured data as a >>>>>>> base, >>>>>>> but have more variation so the simulation does not provide extremely >>>>>>> similar outputs each time. I have set --random to true and >>>>>>> --randomize-flows to true, but that does not provide the variation that >>>>>>> I >>>>>>> seek. I want to know if it is possible to generate outputs that are >>>>>>> still >>>>>>> close to my measured data, but vary between simulations. >>>>>>> >>>>>>> Any ideas are appreciated!! >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>> _______________________________________________ >>> 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
