The cascading types are expected when you call functions that change vType attributes on a singe vehicle (i.e. traci.vehicle.setLength). In order to change the property only for a single vehicle, the type is cloned every time. However, the reported information is insufficient to understand the problem. Please provide a minimal failure example. Instead of the traci script, please provide a full log of the traci commands as described here: https://sumo.dlr.de/docs/TraCI/Interfacing_TraCI_from_Python.html#generating_a_log_of_all_traci_commands
Am Mo., 27. März 2023 um 19:40 Uhr schrieb Stefano Bonasera < [email protected]>: > Hi Jakob, > > Thanks for the prompt reply. > What I see in the vType in the saved file for both types is: > > <vType id="other" minGap="2.000000000000" maxSpeed="35.000000000000" > speedFactor="normc(1.000000000000,0.100000000000,0.200000000000,2.000000000000)" > impatience="0.500000000000" maxSpeedLat="1.000000000000" > latAlignment="center" minGapLat="0.600000000000" laneChangeModel="SL2015" > lcStrategic="1.0" lcCooperative="1.0" lcSpeedGain="1.0" lcKeepRight="1.0" > lcSublane="1.0" lcPushy="1" lcPushyGap="0" lcAssertive="1.0" > lcImpatience="0.001" lcTimeToImpatience="100" lcAccelLat="10" > lcLookaheadLeft="2.0" lcSpeedGainRight="1.0" carFollowModel="IDM" > accel="3.0" decel="5.5" tau="0.1"/> > > <vType id="rl" minGap="0.000000000000" maxSpeed="35.000000000000" > speedFactor="normc(1.000000000000,0.100000000000,0.200000000000,2.000000000000)" > impatience="0.500000000000" maxSpeedLat="1.000000000000" > latAlignment="center" minGapLat="0.600000000000" laneChangeModel="SL2015" > lcStrategic="1.0" lcCooperative="1.0" lcSpeedGain="1.0" lcKeepRight="1.0" > lcSublane="1.0" lcPushy="1" lcPushyGap="0" lcAssertive="1.0" > lcImpatience="0.001" lcTimeToImpatience="100" lcAccelLat="10" > lcLookaheadLeft="2.0" lcSpeedGainRight="1.0" carFollowModel="IDM" > accel="3.0" decel="5.5" tau="0.1"/> > > I tried to play around also with the minGap (only difference I see between > these two vTypes) and that is indeed influencing the headway - only for the > rl type: > 1) If minGap = 0: I get the headway as reported above: pre load: 245.65, > post load and subscribe: 243.15 (from > kernel_api.vehicle.getSubscriptionResults(rl_id)) > 2) If minGap = 2: pre load: 245.65, post load and subscribe: 245.15 > 3) If minGap = 3: pre load: 245.65, post load and subscribe: 246.15 > > Moreover, if I setLength of a vehicle (as in case #2 above) I see that > multiple vTypes are generated with "cascade-like" vType ids as "rl@rl0 > @rl0'''. > > Stefano > > > On Fri, Mar 24, 2023 at 3:39 AM Jakob Erdmann <[email protected]> > wrote: > >> This sounds as if something goes wrong when loading the type of the rl >> vehicle. Please look into the saved state file and post the line that >> defines the vType of the rl vehicle. >> >> Am Do., 23. März 2023 um 14:47 Uhr schrieb Stefano Bonasera < >> [email protected]>: >> >>> Hello, >>> >>> I use sumo 1.16, interfacing with python. >>> I noticed a weird behavior when loading and saving state and I hope you >>> can help me explain the motivation behind it >>> >>> I have only two types of vehicles in my simulation (other and rl). >>> Assume the rl vehicle has as a lead vehicle, say, "flow_15" with an headway >>> of 245.65. I save the state via saveState, and immediately after load the >>> same exact state via loadState. After loading the state I notice that: >>> 1) If I subscribe the quantities I care about + the leader (subscribe() >>> + subscribeLeader()) for the rl vehicle and I request the subscription >>> results for the same vehicle, the correct leader shows up, but the headway >>> is reduced by half the rl vehicle car length, i.e. 243.15, assuming I am >>> using the default value of 5 >>> 2) If I subscribe the rl vehicle (including also VAR_LENGTH), set the >>> length of the vehicle via setLength() and then subscribe the leader through >>> subscribeLeader, then both the correct lead vehicle and headway show up >>> from the subscriptionResults >>> >>> This change in headway happens only for the type of vehicle "rl", not >>> for the "other" type of vehicle, which present in the subscriptionResults >>> the correct lead vehicle and associated headway. >>> Is it an intended behavior or am I missing something? >>> Do you have a better approach to prevent this difference? >>> >>> Thanks a lot for all the continuous support! >>> >>> -- >>> Kind regards, >>> Stefano. >>> _______________________________________________ >>> 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 >> > > > -- > Kind regards, > Stefano. > _______________________________________________ > 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
