Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-user] Increased variation when using DFROUTER
I tried this and it looks like I am not mixing versions.  I actually had to get a new laptop and downloaded the most recent development version and got the same error.  When I moved edgeDataFromFlow.py and detector.py from the detector folder to the tools folder it worked, but routesampler.py did not.  routesampler.py gives me an importerror about numpy, even though numpy is installed and on the path.  Is moving edgeDataFromFlow.py and detector.py a bad idea?  I'm not really sure where my error is but I'm almost positive that it has to do with the locations where python and sumo are saved.  I just want to make sure it does not have to do with me moving the files around.  

On Fri, Aug 28, 2020 at 2:02 AM Jakob Erdmann <namdre.sumo@xxxxxxxxx> wrote:
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 <sumoquestions@xxxxxxxxx>:
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 <namdre.sumo@xxxxxxxxx> 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 <sumoquestions@xxxxxxxxx>:
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 <namdre.sumo@xxxxxxxxx> 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 <sumoquestions@xxxxxxxxx>:
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 <namdre.sumo@xxxxxxxxx> 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 <sumoquestions@xxxxxxxxx>:
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
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
_______________________________________________
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

Back to the top