Re: [sumo-user] misbehaviour of LuST simulation

2020-09-10 Thread Lara Codeca
Hello,

I don't know about the ContextSubscription part of it, but the reason why
you should "only use version 0.26 for the LuST scenario" is because I built
and validated the mobility with it. Newer versions of SUMO have better and
improved mobility models and the congestion levels in parts of the city are
very different. This is actually what I think is happening with the
different number of vehicles.
If SUMO cannot insert the vehicles due to congestion, they sort of time out
and get discarded.

Hope it helps.

Regards,
Lara

On Thu, Sep 10, 2020 at 10:36 AM blubb  wrote:

> Dear user group,
>
> I experienced misbehaviour in my LuST simulation. The problem is that
> the simulation I ran recently has way more traces than anticipated. I
> will attach the source code (extracttraces.py) for the simulation as
> well as the lust.config.
>
> Basically I want to generate traces over one day and insert them into
> some database. Also I use the ContextSubscription feature to see if the
> vehicles are within observation radius of some specific junctions (the
> 50 with most traffic throughput).
>
> When I ran the simulation a few months ago I got about 209 Mio traces
> with 214315 different vehicles. Unfortunately I can't determine the
> source code and config of this simulation, but it should have been the
> same as I use now.
>
> However when I run the simulation now I get more than the double amount
> of traces (427 Mio) with slightly less vehicles (213424).
>
> So somehow the new simulation generated way more traces which is very
> unfortunate.
>
> By comparing the both databases I found out that both of them have
> roughly the same amount of trace within the simulation time 0s < time <
> 6s  (around 90 Mio traces).
>
> At some point after this the new database and the old one diverge in the
> number of traces.
>
> (6s < time < 86400s : old : 120 Mio, new 338 Mio traces).
>
> So something is going wrong there but I can't figure out what it is.
>
> It could be that I ran the old dabase on an older version of sumo. The
> new one is running on sumo 1.6.0.
>
> I recently read that I should only use version 0.26 for the LuST
> scenario, but it is hard to imagine that this misbehaviour comes from
> different versions.
>
> However, if you have any advice for me I will be glad to hear from you.
>
> Kind regards
>
> Knut
>
>
> ___
> sumo-user mailing list
> sumo-user@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/sumo-user
>
___
sumo-user mailing list
sumo-user@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/sumo-user


[sumo-user] misbehaviour of LuST simulation

2020-09-10 Thread blubb
Dear user group,

I experienced misbehaviour in my LuST simulation. The problem is that
the simulation I ran recently has way more traces than anticipated. I
will attach the source code (extracttraces.py) for the simulation as
well as the lust.config.

Basically I want to generate traces over one day and insert them into
some database. Also I use the ContextSubscription feature to see if the
vehicles are within observation radius of some specific junctions (the
50 with most traffic throughput).

When I ran the simulation a few months ago I got about 209 Mio traces
with 214315 different vehicles. Unfortunately I can't determine the
source code and config of this simulation, but it should have been the
same as I use now.

However when I run the simulation now I get more than the double amount
of traces (427 Mio) with slightly less vehicles (213424).

So somehow the new simulation generated way more traces which is very
unfortunate.

By comparing the both databases I found out that both of them have
roughly the same amount of trace within the simulation time 0s < time <
6s  (around 90 Mio traces).

At some point after this the new database and the old one diverge in the
number of traces.

(6s < time < 86400s : old : 120 Mio, new 338 Mio traces).

So something is going wrong there but I can't figure out what it is.

It could be that I ran the old dabase on an older version of sumo. The
new one is running on sumo 1.6.0.

I recently read that I should only use version 0.26 for the LuST
scenario, but it is hard to imagine that this misbehaviour comes from
different versions.

However, if you have any advice for me I will be glad to hear from you.

Kind regards

Knut


from __future__ import print_function
import time as t

starttime = t.time()
import os, sys, sqlite3
import random



 Einstellungen 

# Path to sumo tools (version 1.6.0)
tools_path = "/opt/sumo-1.6/tools"

db_path_lw = "/media/ssd/berling/lwdb/lwdb.sqlite"
db_path_junctions = "/media/ssd/berling/all_junctions.sqlite"
db_path_traces = "/media/ssd/berling/sumo24htest50.sqlite"

# lust_0to24.sumocfg  is attached in the email 
config_path = os.path.join(os.getcwd(), "./res/lust_0to24.sumocfg")

# start sumo
command = ["sumo", "-c", config_path, "--xml-validation", "never"]

# observed junction ID's controlled by an attacker 
#(in this case he controls the 50 traffic junctions with the most traffic throughput)
dbconj = sqlite3.connect(db_path_junctions)
cursorj = dbconj.cursor()
cursorj.execute("SELECT jid FROM junctions ORDER BY density DESC LIMIT 50")
res = cursorj.fetchall()
observed_jids = []
for r in res:
observed_jids.append(str(r[0]))
dbconj.close()

# observation radius within the junction
radius = 100

sim_start = 0
sim_end = 86400

###


sys.path.append(tools_path)
import traci, traci.constants as const

# extract random sizes from some databas
# those size will be assigned to vehicles later
def sample_sizes():
dbconlw = sqlite3.connect(db_path_lw)
cursorlw = dbconlw.cursor()
cursorlw.execute("SELECT Length, Width,ROW_COUNT FROM joined_tables")
results_lw = [{'Length': col1, 'Width': col2, 'ROW_COUNT': col3} for (col1, col2, col3) in cursorlw.fetchall()]
lux_vektor = []
for col in results_lw:
count = 1
while count <= col['ROW_COUNT']:
lux_vektor.append([col['Length'], col['Width']])
count += 1
dbconlw.close()
return random.sample(lux_vektor, len(lux_vektor))


print("\nSimulation und Extraktion der Traces")
print("")

print("Datenbank: %s\nBefehl: %s\nStartzeit: %i\nEndzeit: %i" % (db_path_traces, command, sim_start, sim_end))

if os.path.exists(db_path_traces):
print("Verbinde zur Datenbank...")
else:
print("Erstelle Datenbank...")
dbcon = sqlite3.connect(db_path_traces)
cursor = dbcon.cursor()

print("Leere Datenbank...")
cursor.execute("DROP TABLE IF EXISTS traces")
cursor.execute("VACUUM")
dbcon.commit()
cursor.execute('''CREATE TABLE traces (vid TEXT NOT NULL, time INTEGER NOT NULL, Length INTEGER, Width INTEGER,
x_location REAL NOT NULL, y_location REAL NOT NULL, pseudonym TEXT, event TEXT, observed_at_jid TEXT, distance REAL, PRIMARY KEY(vid,time))''')
dbcon.commit()

print("Starte SUMO...")
traci.start(command)
for jid in observed_jids:

traci.junction.subscribeContext(jid, const.CMD_GET_VEHICLE_VARIABLE, radius, [const.TRACI_ID_LIST])

lux_vid = {}
lux_samples = sample_sizes()
lux_vid_step = 0
time = sim_start
values = []
while time <= sim_end:
traci.simulationStep()
vids = traci.vehicle.getIDList()
for vid in vids:

if not lux_vid.has_key(vid):
# add length and width if vehicle is not known
length = lux_samples[lux_vid_step][0]
width = lux_samples[lux_vid_step][1]
lux_vid[vid] = lux_samples[lux_vid_step]  #