mismatch between traci.inductionloop.getLastIntervalVehicleNumber and xml attribute nVehContrib

[HowRuck]

Hi,

im currently working on creating a client which uses data generated by SUMO to train Graph-Neural Networks. For this i need to process the aggregated output of lane detectors every x steps.

The problem i found with this is, that when configuring the detectors to write/output their data every x steps and reading the associated XML file to retrieve/load data at simulation step x, the contents of the XML file are incomplete when using libsumo. When instead using Traci the output is correct.

When using the following code (new detector output is generated every 60 steps, tested with the bologna/pasubio scenario)

curr_sim_step = 0
libsumo.start(sumoCmd)
while curr_sim_step < settings["sim_length"]):
    libsumo.simulationStep()
    if (curr_sim_step % 60 == 0 and curr_sim_step != 0):
        break
    curr_sim_step += 1

the output-XML file is incomplete (last three lines of the output file):

    <interval begin="0.00" end="60.00" id="2.19_0.127_2_1__l1" nVehContrib="0" flow="0.00" occupancy="0.00" speed="-1.00" harmonicMeanSpeed="-1.00" length="-1.00" nVehEntered="0"/>
    <interval begin="0.00" end="60.00" id="2.19_2.18_4_1__l0" nVehContrib="2" flow="120.00" occupancy="1.19" speed="14.02" harmonicMeanSpeed="14.01" length="5.00" nVehEntered="2"/>
    <interval begin="0.00" end="60.00" id="2.19_2.18_4_1__l1" nVehContrib="2" flow="120.00" occupancy="

After calling libsumo.close() the output is generated correctly. The output for the interval (0-60) is also correctly available after processing step 120 (with data for interval(60-120) being incomplete)

When replacing libsumo with traci in the code above, the output file is generated correctly and can be parsed (last three Lines of the output file).

    <interval begin="0.00" end="60.00" id="2.30_0.127_2_1__l0" nVehContrib="0" flow="0.00" occupancy="0.00" speed="-1.00" harmonicMeanSpeed="-1.00" length="-1.00" nVehEntered="0"/>
    <interval begin="0.00" end="60.00" id="2.30_0.127_2_1__l1" nVehContrib="0" flow="0.00" occupancy="0.00" speed="-1.00" harmonicMeanSpeed="-1.00" length="-1.00" nVehEntered="0"/>
</detector>

As it can be seen, the output file, generated when using libsumo, is incomplete and can not be parsed, while the file generated when using traci is generated correctly

SUMO-version: 1.16.0 operating system: Linux (Fedora 37) Python 3.11

[namdre]

The xml files are generally not flushed until the simulation end so their contents at any time before that are subject to buffering by the operating system. I'm not sure why it happens to work when running with traci but I would advise against relying on this behavior. A more reliable method is to access the aggregated data directly using any of the methods that have Interval in their name. i.e. traci.inductionloop.getLastIntervalVehicleNumber

[HowRuck]

I have another quick question if you don`t mind

I now access the data using the methods you mentioned (e.g. getLastIntervalVehicleNumber) but the result seems to be inconsistent with the data in the XML File generated by SUMO

traci.start(sumoCmd)
curr_sim_step = 0
while curr_sim_step < int(settings["sim_length"]):
    traci.simulationStep()
    if (curr_sim_step % 60 == 0 and curr_sim_step != 0):
        print(traci.inductionloop.getLastIntervalVehicleNumber("2.17_2.18_8_1__l1"))

    curr_sim_step += 1
traci.close()

When running this (sensor aggregation interval is 60 steps), the data provided by Traci doesn't match the data in the XML-file generated by sumo

For example the code above outputs that 11 vehicles passed the detector at the interval (120, 180) while the value in the XML-File generated by SUMO is 12

[namdre]

this sounds like it may be a mismatch between considered intervals. Please do the following:

1. print the lastIntervalVehicleNumber in every step
2. compare the sequence of values with the xml output

The expectation is that the values of 1) should change only every 60s and that the values should line up with those of 2)

[HowRuck]

Okay, ive just done that and the results are the following:

Code:

traci.start(sumoCmd)
curr_sim_step = 0
while curr_sim_step <= 300:
    traci.simulationStep()
    print(curr_sim_step, traci.inductionloop.getLastIntervalVehicleNumber("2.17_2.18_8_1__l1"))
    curr_sim_step += 1
traci.close()

Definition of detector in additional file:

<e1Detector id="2.17_2.18_8_1__l1" lane="1[0]_1" pos="329" freq="60" file="e1_output.xml"/>

Console output:

0 0
[...]
58 0
59 4
60 4
[...]
118 4
119 12
120 12
[...]
178 12
179 11
180 11
[...]
238 11
239 10
240 10
[...]
298 10
299 13
300 13

Values for all intervals of the sensor:

<interval begin="0.00" end="60.00" id="2.17_2.18_8_1__l1" nVehContrib="4" flow="240.00" occupancy="3.23" speed="13.62" harmonicMeanSpeed="13.60" length="4.62" nVehEntered="6"/>
<interval begin="60.00" end="120.00" id="2.17_2.18_8_1__l1" nVehContrib="12" flow="720.00" occupancy="14.30" speed="9.40" harmonicMeanSpeed="6.44" length="4.79" nVehEntered="12"/>
<interval begin="120.00" end="180.00" id="2.17_2.18_8_1__l1" nVehContrib="12" flow="720.00" occupancy="8.19" speed="12.90" harmonicMeanSpeed="12.65" length="4.79" nVehEntered="13"/>
<interval begin="180.00" end="240.00" id="2.17_2.18_8_1__l1" nVehContrib="10" flow="600.00" occupancy="10.99" speed="9.80" harmonicMeanSpeed="7.61" length="4.80" nVehEntered="11"/>
<interval begin="240.00" end="300.00" id="2.17_2.18_8_1__l1" nVehContrib="13" flow="780.00" occupancy="22.56" speed="8.92" harmonicMeanSpeed="4.58" length="4.81" nVehEntered="12"/>

The issue seems to still exist, as the value for the interval (120, 180) provided by traci should be (according to the XML file) 12 instead of 11 (if i understand it correctly)

[namdre]

can you provide minimal input files for reproducing the issue?

[HowRuck]

Sure, here is the code and input files that should reproduce the issue code.zip

Side-note: since i reduced the number of input files, the "broken" intervals have changed and are now (240, 300) and (300 360). There are also more inconsistencies when increasing the simulation length. I also found out that there are inconsistencies with getLastIntervalOccupancy (noticeable at interval (240, 300) and (300, 360) ) and getLastIntervalMeanSpeed (noticeable at intervals (240, 300) and (300, 360)) as well.

I hope i didn`t forget anything and that you can reproduce the issue :)