resupport traffic trace, standardise direction

[chestnutcase]

hi v2x maintainers,

i actually have been studying this simulator and adding my own functionality for my own phd studies, and i intend to merge some of the functionality i have made back upstream, if you approve it.

For this first PR, I readded support for loading traffic trace files. The traffic trace file uses the old format of

time, vehicle_id, x, y, [speed]

the last column is optional.

I also standardised the unit of simValues.direction / positionManagement.direction, to be the angle bearing in radians (i.e. the result from atan2(y,x) so that you can easily calculate displacement using dx = r*cos(d) dy = r*sin(d); previously the units for direction depended on the scenario which leads to alot of awkward if-eleses but i am standardising it for future maintainers.

[wzf-cn]

Hi Chester Koh,

Thanks for your interest and contribution!

Based on your PR/22, I rewrite the direction as complex number because one of our on going project is doing it this way.

And I'm not sure if the trace file works now, because I got some errors that activeID and distanceReal may not match each other.

Do you have any suggestions about the new commit?

[chestnutcase]

hi wzf-cn,

okay, then i suggest we always convert to complex numbers in positionManagement.direction, regardless of the scenario.

i double check if tracefiles are working based on your latest commit

[chestnutcase]

I tested with my own trace file that I generated, it has four columns (missing the velocity column), it doesn't show any errors can I have the link to the BolognaAPositions.txt trace file? I'm not sure where to get it Attached is my own trace file I used 4_vehicles_incoming.txt

[wzf-cn]

You could find trace files in the other repository[TrafficTraces](https://github.com/V2Xgithub/TrafficTraces)

[chestnutcase]

just to clarify, what does it mean for a vehicle to have "exited" the scenario? must every time epoch in the trace file have all active vehicle IDs? (which means that a consecutive number is missing for a certain time instant, it means it exited?)

[wzf-cn]

When we check a specific area on a map, some cars would go in while others may go out now and then. In this case, if we give each car an unique ID, the trace file would miss some IDs because they went out of the area.

The trace file would not have to log all of the IDs (including the out boundary ones), but the simulator should be able to deal with it. The earlier version works fine with it, but later, when we deal with other functions, this capability was broken...

[chestnutcase]

okay, i am still trying to understand how the simulator should behave with exited vehicles.

so, only if the vehicle's coordinates is outside the rectangular bounds (Xmax Ymax), then it is considered as exit?

if a vehicle id does not have further updates in the trace file after a certain time t (like it does not appear in the remaining lines of the trace file), but its position is still inside the bounds, should the simulator still treat it as an active vehicle? for example, it pretends it has parked, but it still is "active" and requests beacons resources.

[chestnutcase]

i discovered something important: the interpolateTrace function run at the start attempts to delete some vehicle IDs from the trace, causing the vehicle IDs to no longer be sequential. I believe loadTrafficeTrace will already normalize the vehicle IDs to be sequential (if not, I added my own normalization function in just a few lines)

But I don't understand why interpolating the trace will result in some vehicles being deleted entirely, I don't quite understand the intent behind the code. If we can agree that we should not delete vehicles from the trace and just interpolate, I can do it easily using MATLAB's retime function.

The block of code does the interpolation (in addition to somehow removing some vehicles entirely) is here:

for idToCheck = min(dataOrig(:,2)):max(dataOrig(:,2))

[V2Xgithub]

Dear Chester, we decided at that time to consider a vehicle active only if its position is updated at every time interval and to remove it otherwise.

The reason is that you may wish to simulate a car that is stopped but active or a car that stops and turns off the radio.

We also had to face with the possibility that cars exit from the scenario before the end of the simulation or that enter the scenario later than the beginning. This easily happens whenever you take a trace file generated for other scopes, especially if you want simulate only a portion of the entire scenario. Re-sequencing the numbers does not completely solve the problem, since the number of cars in the scenario may not be always the same.

One key consequence of this is that you may have 50000 cars if you count as a new ID each entering and exiting, but then only say 1000 that are really active. And creating large matrixes (50k x 50k) for the calculation of channel gain is not good for the performance of the simulator. To solve this, we decided to have a list of cars based on the ID, which goes in our example from 1 to 50000, but also a list of active users, which is much much smaller (1 to 1000 in the example). Each active user has an index that points to the ID. The full list is used for most of the parameters in the simulator and especially the outputs, whereas the indexes are used for large matrixes for frequent calculations like those for the average SINR.

The presence of IDs and Indexes creates a bit of confusion at the beginning, but we thought it was the best compromise between efficiency and code readability.

I think that these choices are still the preferable ones. I would not change these aspects.

I would therefore not introduce your proposal in this case, even if it is clearly reasonable and well reasoned.

Alessandro Bazzi, Ph.D. Associate Professor @ DEI, Università di Bologna Associated with WiLab, CNIT www.alessandrobazzi.comhttp://www.alessandrobazzi.com/ Phone: +39-051-2093880

---

Da: Chester Koh @.> Inviato: mercoledì 4 ottobre 2023 17:03 A: V2Xgithub/WiLabV2Xsim @.> Cc: Subscribed @.***> Oggetto: Re: [V2Xgithub/WiLabV2Xsim] resupport traffic trace, standardise direction (PR #22)

i discovered something important: the interpolateTrace function run at the start attempts to delete some vehicle IDs from the trace, causing the vehicle IDs to no longer be sequential. I believe loadTrafficeTrace will already normalize the vehicle IDs to be sequential (if not, I added my own normalization function in just a few lines)

But I don't understand why interpolating the trace will result in some vehicles being deleted entirely, I don't quite understand the intent behind the code. If we can agree that we should not delete vehicles from the trace and just interpolate, I can do it easily using MATLAB's retime function.

The block of code does the interpolation (in addition to somehow removing some vehicles entirely) is here:

for idToCheck = min(dataOrig(:,2)):max(dataOrig(:,2))https://github.com/V2Xgithub/WiLabV2Xsim/blob/557c68d725aa7d423d00ebc946eb3e55b7234c2d/MatFilesPosition/interpolateTrace.m#L68

— Reply to this email directly, view it on GitHubhttps://github.com/V2Xgithub/WiLabV2Xsim/pull/22#issuecomment-1747004825, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AUR65OSWYL5ZRUQTMMGYQJTX5V3FJAVCNFSM6AAAAAA5JFUDKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBXGAYDIOBSGU. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[chestnutcase]

Dear Alessandro,

Alright, I better understand the simulator requirements. I am still interested in using trace files because the majority of my studies is about reviewing the behaviour of the various algorithms in specially crafted edge cases.

From my current testing, trace files appear to currently work if

1. The vehicle id's are perfectly sequential starting from 1
2. No vehicles enter or exit the scenario in the middle of the simulation

I definitely agree with the need for the simulator to a changing list of vehicles, hence the need to distinguish between a "canonical" vehicle id/name (this could even be things like an RSU), in addition to an internal entity id used for indexing in tight loops like SINR calculation / BR allocation. However, as it appears, new functionality introduced later in the simulator is not compatible with this behaviour. Refactoring to fix this would take some time but I am definitely interested in helping out.

But for now, perhaps you could consider merging this branch for partial support for trace files subject to the conditions above, if old functionality hasnt been removed. It would still be useful for some studies. We can work on the full support together eventually.

Regards, Chester

On Thu, 5 Oct 2023, 16:59 V2Xgithub, @.***> wrote:

Dear Chester, we decided at that time to consider a vehicle active only if its position is updated at every time interval and to remove it otherwise.

The reason is that you may wish to simulate a car that is stopped but active or a car that stops and turns off the radio.

We also had to face with the possibility that cars exit from the scenario before the end of the simulation or that enter the scenario later than the beginning. This easily happens whenever you take a trace file generated for other scopes, especially if you want simulate only a portion of the entire scenario. Re-sequencing the numbers does not completely solve the problem, since the number of cars in the scenario may not be always the same.

One key consequence of this is that you may have 50000 cars if you count as a new ID each entering and exiting, but then only say 1000 that are really active. And creating large matrixes (50k x 50k) for the calculation of channel gain is not good for the performance of the simulator. To solve this, we decided to have a list of cars based on the ID, which goes in our example from 1 to 50000, but also a list of active users, which is much much smaller (1 to 1000 in the example). Each active user has an index that points to the ID. The full list is used for most of the parameters in the simulator and especially the outputs, whereas the indexes are used for large matrixes for frequent calculations like those for the average SINR.

The presence of IDs and Indexes creates a bit of confusion at the beginning, but we thought it was the best compromise between efficiency and code readability.

I think that these choices are still the preferable ones. I would not change these aspects.

I would therefore not introduce your proposal in this case, even if it is clearly reasonable and well reasoned.

Alessandro Bazzi, Ph.D. Associate Professor @ DEI, Università di Bologna Associated with WiLab, CNIT www.alessandrobazzi.comhttp://www.alessandrobazzi.com/ Phone: +39-051-2093880

---

Da: Chester Koh @.> Inviato: mercoledì 4 ottobre 2023 17:03 A: V2Xgithub/WiLabV2Xsim @.> Cc: Subscribed @.***> Oggetto: Re: [V2Xgithub/WiLabV2Xsim] resupport traffic trace, standardise direction (PR #22)

i discovered something important: the interpolateTrace function run at the start attempts to delete some vehicle IDs from the trace, causing the vehicle IDs to no longer be sequential. I believe loadTrafficeTrace will already normalize the vehicle IDs to be sequential (if not, I added my own normalization function in just a few lines)

But I don't understand why interpolating the trace will result in some vehicles being deleted entirely, I don't quite understand the intent behind the code. If we can agree that we should not delete vehicles from the trace and just interpolate, I can do it easily using MATLAB's retime function.

The block of code does the interpolation (in addition to somehow removing some vehicles entirely) is here:

for idToCheck = min(dataOrig(:,2)):max(dataOrig(:,2))< https://github.com/V2Xgithub/WiLabV2Xsim/blob/557c68d725aa7d423d00ebc946eb3e55b7234c2d/MatFilesPosition/interpolateTrace.m#L68>

— Reply to this email directly, view it on GitHub< https://github.com/V2Xgithub/WiLabV2Xsim/pull/22#issuecomment-1747004825>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/AUR65OSWYL5ZRUQTMMGYQJTX5V3FJAVCNFSM6AAAAAA5JFUDKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBXGAYDIOBSGU>.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/V2Xgithub/WiLabV2Xsim/pull/22#issuecomment-1748420713, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHVWVVDJHYBLW2HUSR7GNSDX5ZZHJAVCNFSM6AAAAAA5JFUDKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBYGQZDANZRGM . You are receiving this because you authored the thread.Message ID: @.***>

[wzf-cn]

Hi Chester,

I start a new branch "dev-parallel-and-tracefile" for developing and would merge these PR into it. After we test the proposed ideas, this branch would be merged into the main branch.