Multiple runs in omnet++ but with new network - omnet++

I am trying to get different results for the code I have written in veins. I would like to run simulation multiple times to get average of all result. Issue I am facing is when I use repeat=5 i get exact same result in all 5 runs. I want to regenerate the network each time it repeats. I have written code to place RSUs in random positions but i get same result. What I can try?

Frist of all, see the TicToc Tutorial.
For your issue, you need to set a seed for each run as the OMNet Manual show
For me, the best way is set seed-set as the repetition number(repeat)
seed-set = ${repetition}

To start all repetitions of a simulation go to Run Configurations and set Cmdenv as User interface and:
for OMNeT++ 5.0 or older: set * (asterisk) in Runnumber
for OMNeT++ 5.1: set 0..4 in Run(s)
As a result you will obtain five set of results.
Optionally you can choose more than one processes to run in parallel or CPUs/processes to use in Run Configurations.

Related

What is the effect of changing the SEED in OMNET++ VS in SUMO for Vehicular Network simulation?

I noticed that setting the seed-set in the "ini" file for a Veins-OMNET++ simulation, will only affect the communication-related values by comparing different runs at a specific time. i.e. at a particular time for different runs, the vehicles' mobilities values (x,y, speed, direction) are relatively the same. Could you please confirm that?
However, when I set the <seed value="seedValue" /> in the "mapname.launchd.xml" file, the mobilities of the vehicles change between runs. My second question is, Is changing the seed for SUMO affect the traffic flow (veh/h) set in the route file (.rou.xml)?
seed-set controls OMNeT++/Veins parameters defined as random variables in your omnetpp.ini file, something like **.packetSize = uniform(100B, 500B). SUMO's seed does the same job on the SUMO side. I assume you use VeinsInetMobility in your scenario -- in that case your speed and positions distribution is controlled by SUMO's seed since all computations are happening there, if you use any of inet's internal mobilities and set it in omnetpp.inifile -- then it is controlled by seed-set.

How to configure sumo-launchd.py to get Lanearea Detectors output?

I am learning sumo and Veins, using the F2MD framework for simulation, but I have encountered some problems. I am trying to get Lanearea Detectors output with sumo, when I can use the command:"sumo-gui -a lust.add.xml"(which already set Lanearea Detectors additional) ,I can get the output file like:xxx.output.xml. But when i use sumo-launchd.py to start the same simulation,it don't have any output file , This confuses me, hope someone can help me, thank!
You need to find the sumo configuration which is running and add the line
<additional-files value="lust.add.xml"/>
or add the file to the list if the entry is already present.

Where to view logged results in Veins 5.1

I'm somewhat new to Veins and I'm trying to record collision statistics within the sample "RSUExampleScenario" provided in the VM. I found this question which describes what line to add to the .ini file, which I have, but I'm unable to find the "ncollisions" value in the results folder, which makes me think either I ran the wrong .ini line or am looking in the wrong place.
Thanks!
Because collision statistics take time to compute (essentially: trying to decode every transmission twice: once while considering interference by other nodes as usual, then trying again while ignoring all interference), Veins 5.1 requires you to explicitly turn collision statistics on. As discussed in https://stackoverflow.com/a/52103375/4707703, this can be achieved by adding a line *.**.nic.phy80211p.collectCollisionStatistics = true to omnetpp.ini.
After altering the Veins 5.1 example simulation this way and running it again (e.g., by running ./run -u Cmdenv -c Default from the command line), the ncollisions field in the resulting .sca file should now (sometimes) have non-zero values.
You can quickly verify this by running (from the command line)
opp_scavetool export --filter 'module("**.phy80211p") and name("ncollisions")' results/Default-\#0.sca -F CSV-R -o collisions.csv
The resulting collisions.csv should now contain a line containing (among other information) param,,,*.**.nic.phy80211p.collectCollisionStatistics,true (indicating that the simulation was executed with the required configuration) as well as many lines containing (among other information) scalar,RSUExampleScenario.node[10].nic.phy80211p,ncollisions,,,1 (indicating that node[10] could have received one more message, had it not been for interference caused by other transmissions in the simulation.

OMNeT++: Different results for simulation repetition using the same seed

Used Versions: OMNeT++ 5.0 with iNET 3.4.0
Using OMNeT++ I'm running some simulation with a big amount of repetitions.
In some cases I don't understand the behaviour of my system, so I want to watch the procedure using Qt. Therefore I need the repeat some special cases of the previously simulated repetitions.
Even though I use the exact same configuration-file in combination with the corresponding seedset, I don't get the desired repetion, so I get completly different results. What can be the reason for that?
Analyzing the header of the generated log-files, there are only differences in the following lines:
run General-107342-20170331-15:42:22-5528
attr datetime 20170331-15:42:22
attr processid 5528
All other parameters are matching exactly. I don't understand why the results are different. Is the processid relevant for behavior like this?
Some tips to nail down the problem:
Check if the difference is indeed caused by the Graphical/Non-graphical difference. Run your simulation with both:
$ mysim -r 154 -u Cmdenv
$ mysim -r 154 -u Qtenv
$ mysim -r 154 -u Tkenv
Check the results. Different results may be caused by several issues:
relying on undefined behavior in C++, like you have a (set) collection and you iterate over it. The order of the collection is undefined and it can throw the simulation to a different trajectory
Accessing uninitialized memory
Using data that is available only in graphical runtime, like using the positions of the nodes defined by the #displayString property. Node positions may change based on the layouting algorithm and layouting is not available in Cmdenv
Changing the model state while testing whether the model is running under a graphical runtine i.e. inside if (isGUI()) {} blocs.
First I would try to figure out whether this is related to GUI vs non-GUI or rather the use of undefined behavior. If Tkenv and Qtenv gives the same result while Cmdenv differes, then it is a GUI-nonGUI issue. If all of them is different I would suspect a memory issue or undefined behavior.
If everything else fails, run the simulation in both Cmdenv and Qtenv and turn on event logging. Compare the logs and see where the two trajctories start to diverge and debug both run around that point to see the cause of divergence.

Advice in Time simulation

I just created VANET simulation with AODV protocol .. Then running it using omnet++ and sumo ..please your advice for :-
1- Which button it better to use ( run button , or fast button )
2- When I using the run button, my simulation take along time upto 12 hour with sample number of car .. So if the number of car increase it will take more long time, So how can increase the speed of simulation to get less run time ..
Thanks in advance
For running simulations (for collecting results and after verifying that your model works as intended) I recommend two things:
Run your simulation in release mode. This means compiling the code with the flag MODE=release. More details can be found in the OMNeT++ user manual.
Run your simulations on the command line - do not use any OMNeT++ GUI. If you want to collect results this is by far the fastest way as you do not care about the GUI. How to use the command line is explained in the dedicated OMNeT++ user manual section.

Resources