[sumo-user] misbehaviour of LuST simulation

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[sumo-user] misbehaviour of LuST simulation

Trash Mail
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 <
60000s  (around 90 Mio traces).

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

(60000s < 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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

extracttraces.py (5K) Download Attachment
lust_0to24.sumocfg (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [sumo-user] misbehaviour of LuST simulation

Lara Codeca-2
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 <[hidden email]> 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 <
60000s  (around 90 Mio traces).

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

(60000s < 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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user

_______________________________________________
sumo-user mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user