Thank you for the answer.

After leaving this problem for a few months I had to recently get back at
it and it is still unsolved. However, I found out that:
1) The headway problem at the moment of loading a saved state only happens
for vehicles of type "rl"
2) The 'rl' vehicle is added to the simulation via the self.k.vehicle.add
command, calling the kernel_api.vehicle.addFull inside
3) The other vehicles (of type "other") are added with an inflow - from the
saved state
    <flowState id="flow_00" type="other" begin="1.00" departLane="0"
departSpeed="25.64" probability="0.410184827871"
end="200000000.000000000000" route="routehwy_rear_0" done="11" index="11"/>
4) Looking at the saved state, all vehicles of type "other" have indeed the
type listed, while the same does not happen for the rl vehicle - example:
    <vehicle id="flow_00.9" type="other" depart="16.30" departLane="0"
departSpeed="25.64" color="100,100,100" route="routehwy_rear_0" distance="0
0" speedFactor="1.035700000000" state="2615 16300 0 5.10 0 0.85 20100 0 0"
pos="83.334363758822 78.334363758822 1.944504118608" speed="19.445041186084
19.456978560735" angle="90.000000000000" posLat="0.000000000000"
waitingTime="100000 0"/>
    <vehicle id="rl_0" depart="0.10" departLane="0" departPos="0.00"
departSpeed="20.00" color="red" route="routeramp_0" distance="379.59 0"
speedFactor="1.026700000000" state="29 100 1 0.00 0 4.81 20100 0 0"
pos="20.410000000000 15.410000000000 2.000000000000" speed="20.000000000000
20.000000000000" angle="90.000000000000" posLat="0.000000000000"
waitingTime="100000 0"/>
    <flowState id="flow_00" type="other" begin="1.00" departLane="0"
departSpeed="25.64" probability="0.410184827871"
end="200000000.000000000000" route="routehwy_rear_0" done="11" index="11"/>

I tried to manually modify the saved state file (after saving it, but
before loading it), adding the correct type to the "rl_0", as
<vehicle id="rl_0" type="rl" depart="0.10" departLane="0" ....
and after loading, the correct headway appears within the simulation -> it
seems this is the problem.

>From the add.xml file, everything seems ok:
<?xml version='1.0' encoding='UTF-8'?>
<additional xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:noNamespaceSchemaLocation="http://sumo.dlr.de/xsd/additional_file.xsd";>
  <vType id="rl" accel="3.0" decel="5.5" sigma="0.0" tau="0.1" minGap="2.0"
maxSpeed="35.0" speedFactor="1.0" speedDev="0.1" impatience="0.5"
carFollowModel="IDM" laneChangeModel="SL2015" lcStrategic="1.0"
lcCooperative="1.0" lcSpeedGain="1.0" lcKeepRight="1.0"
lcLookaheadLeft="2.0" lcSpeedGainRight="1.0" lcSublane="1.0" lcPushy="1"
lcPushyGap="0" lcAssertive="1" lcAccelLat="10"/>
  <vType id="other" accel="3.0" decel="5.5" sigma="0.0" tau="0.1"
minGap="2.0" maxSpeed="35.0" speedFactor="1.0" speedDev="0.1"
impatience="0.5" carFollowModel="IDM" laneChangeModel="SL2015"
lcStrategic="1.0" lcCooperative="1.0" lcSpeedGain="1.0" lcKeepRight="1.0"
lcLookaheadLeft="2.0" lcSpeedGainRight="1.0" lcSublane="1.0" lcPushy="1"
lcPushyGap="0" lcAssertive="1" lcAccelLat="10"/>
</additional>

It seems to me the solution is to have the type specified also for the 'rl'
vehicle in the saved state, but I could not find a nice way to have it
besides writing it in the saved state after the saveState command.
Do you have a nicer solution to have the state specified naturally right
after the saveState command?

Thank you in advance for your time and answer.
Stefano


On Sun, Apr 2, 2023 at 7:37 AM Jakob Erdmann <[email protected]> wrote:

> > Please let me know if I am missing anything.
> Reproducing the example requires the sumocfg (sumo.cfg in your log) and
> all files that are referenced within the sumocfg.
>
> > although I do .subscribe() and .subscribeLeader() for the rl vehicle,
> these are not showing in the log file.
> The following occurs in your log file:
>
> traci.vehicle.subscribe('rl_0', [82, 86, 80, 64, 50, 84, 66, 67, 177, 101,
> 132])
> traci.vehicle.subscribeLeader('rl_0', 2000)
> traci.vehicle.subscribe('rl_0', (104,), 0, 2147483647, {104: ('d', 2000)})
> traci.vehicle.unsubscribe('rl_0')
> traci.vehicle.subscribe('rl_0', [82, 86, 80, 64, 50, 84, 66, 67, 177, 101,
> 132])
> traci.vehicle.subscribeLeader('rl_0', 2000)
> traci.vehicle.subscribe('rl_0', (104,), 0, 2147483647, {104: ('d', 2000)})
>
> Am Di., 28. März 2023 um 18:23 Uhr schrieb Stefano Bonasera <
> [email protected]>:
>
>> I have attached the log file I retrieved. Please let me know if I am
>> missing anything.
>> It is interesting to see that, although I do .subscribe() and
>> .subscribeLeader() for the rl vehicle, these are not showing in the log
>> file.
>> Do you have any idea why this is happening?
>>
>> Stefano
>>
>> On Tue, Mar 28, 2023 at 2:32 AM Jakob Erdmann <[email protected]>
>> wrote:
>>
>>> 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
>>>
>>
>>
>> --
>> 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

Reply via email to