Memory issue with many users about monster

[fedech]

We could reduce the resolution of the user mobility, and only move once every 10 or 100 ms. At a normal speed, that would cause no problem and reduce memory occupation by 90%. I can do a pull request and try to fix it

[jakthra]

symMatrix need 4GB of memory with 50 users.

However. Reducing the size of trajectory would be nice, @fedech that would be fantastic.

@artuso0matteo Any idea when it comes to the size of symMatrix? With 50 users it's of size 5x50x1000000

[artuso0matteo]

@fedech thanks for the fix in #27 I'll fix the conflict and merge it into master.
@jakthra for the symMatrix I'll do some digging as right now we use it to compile all the symbols the different stations are going to use and we kind of do padding to pre-allocate the structure in matlab for speed-up. It ends up scaling linearly with the number of users then.
I'll submit a pull request if something smart comes up.

[fedech]

By the way, when I have time (probably next week) I want to fix the mobility codebase, it's a bit of a mess right now. I have a better model in the fork I'm using for the tierless paper, but I can make it easier to integrate other mobility models by putting everything in one place (so that you only have to write a new function to implement a new model instead of making changes in 5 different places)

[artuso0matteo]

Cool! Ok, so i looked into the symMatrix and we use it pretty much only for recording the SER, which we don't really have a use for, considering that we can just rely on the BER. I will then get rid of it and refactor a bit the code in a way that is not needed at all

[jakthra]

Two fixes has been completed. See #29 #27
@mychele @fedech can you verify this fixed some of the memory issues?

[mychele]

No more out of memory error, and stable memory consumption at 7% out of 16GB for 100 users.

[artuso0matteo]

Closing the issue, #29 and #27 solves the problems reported