Menu
▾
▴
Re: [sumo-user] Vehicles Are Using only One Lane (UNCLASSIFIED)
|
From: Olivia B. <Oli...@ci...> - 2010-03-30 17:29:06
|
Dawne, Just a related question: I know the documentation says that in a flow the vehicles have an equal interarrival time period - is there any way of randomising this a little?? Many thanks Olivia -----Original Message----- From: Deaver, Dawne CIV USA AMC [mailto:daw...@us...] Sent: 30 March 2010 18:09 To: sum...@li... Subject: [sumo-user] Vehicles Are Using only One Lane (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE Sorry - forgot to change the Subject heading... Naveen, In your vehicle definitions, try specifying depart-lane "free" or depart-lane "random" as per the documentation found at: http://apps.sourceforge.net/mediawiki/sumo/index.php?title=Specification #Vehicles For example, my routing command looks something like: duarouter --net=osm.net.xml --output-file=osm.rou.xml --flow-definition hwy.flows.xml -b 0 -e 600 --departlane free --randomize-flows --continue-on-unbuild -Dawne ------------------------------ Message: 7 Date: Mon, 29 Mar 2010 09:38:09 -0700 From: Neveen Shlayan <nev...@gm...> Subject: [sumo-user] Vehicles Are Using only One Lane To: sum...@li... Message-ID: <773...@ma...> Content-Type: text/plain; charset=ISO-8859-1 Hi All, I'm doing the routing for my network. I tried a few things: 1. Routing by hand (including single vehicle definition and flow definition) 2. Also Random routing I noticed that the vehicles in either case are using only the rightmost lane. Now when I increase number of vehicles generated in the Random generator I see some vehicles in the lane next to the rightmost one. Is there a way the generated vehicles can some how be distributed among all lanes in a certain edge? Thank you, Neveen ------------------------------ Message: 8 Date: Tue, 30 Mar 2010 17:33:54 +0200 From: Bj?rn Hendriks <hen...@ib...> Subject: Re: [sumo-user] Meaning of lane link length To: Daniel Krajzewicz <d.k...@go...> Cc: sum...@li... Message-ID: <201...@ib...> Content-Type: Text/Plain; charset="iso-8859-15" Hi Daniel, thanks for your answer. On Monday 29 March 2010 15:11:20 wrote Daniel Krajzewicz: > Just because of currently refactoring the code: I am not sure whether this > really aplies to the current SVN state. Sorry. I just had a detailed look into the code (still at revision 8508) and this is what I found out. Please correct me if I'm wrong. The code for vehicles passing into the subsequent lanes seems to be in MSVehicle::moveFirstChecked after comment "// move on lane(s)" (line 918) in the else-block of "if (myState.myPos<=myLane->getLength())" (line 923). There only MSLane::getLength but no MSLink::getLength seems to be used. (BTW, the initialization of driven in line 927 with the ?-operator seems to be always the first alternative of the ?-operator due to the preceding if.) According to my IDE (KDevelop4) the only place where MSLink::getLength seems to be used (beside value retrieval of TraCI) is in MSRoute::getDistanceBetween if HAVE_INTERNAL_LANES is set which is the case in my installation (I only deactivated internal lanes with option no-internal-links of netconvert). The result of MSRoute::getDistanceBetween is only used in MSVehicle::getDistanceToPosition which is only used in TraCIServer::handleVehicleDomain in case DOMVAR_DRIVINGDISTANCE (line 2288) which seems to compute the result of TraCI scenario command, domain vehicle, variable driving distance. So my conclusion is that those link lengths have currently (revision 8508 as mentioned) no meaning for the simulation but are wrongly added to the driving distance of the respective scenario command of TraCI if compiled with HAVE_INTERNAL_LANES. Should I write a bug report or am I wrong? Regards Bj?rn P.S.: Updating to revision 8536 and comparing with the analyzed revision shows no relevant changes. ------------------------------ ------------------------------------------------------------------------ ------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ------------------------------ _______________________________________________ sumo-user mailing list sum...@li... https://lists.sourceforge.net/lists/listinfo/sumo-user End of sumo-user Digest, Vol 44, Issue 18 ***************************************** Classification: UNCLASSIFIED Caveats: NONE Classification: UNCLASSIFIED Caveats: NONE ------------------------------------------------------------------------ ------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ sumo-user mailing list sum...@li... https://lists.sourceforge.net/lists/listinfo/sumo-user |