Model Calibration based on Queue Length Distribution in AnyLogic - anylogic

I have come across a quite complex scenario. I have actual data of the following:
Queue length distribution
Queue waiting time distribution
Distribution of the number of agents arriving every day (but not their pattern of arrival throughout the day)
The process can be assumed as a simple "source > queue > delay > sink"
Is there a way to find an arrival rate and a delay time distribution to match the available actual data? I understand that mathematically there might be many solutions to such a problem. But is there a way at all to approach this situation in AnyLogic?
I managed to meet the average queue length and average waiting time but as a distributions, the queue length and queue waiting time are not close to the actual data set.

This is a parameter calibration problem, in which your parameters are the lambdas of your poisson arrival rate for each hour of the day or so, and the parameters of a triangular distribution for your waiting times (delay).
The arrival rates are always poisson, so no need to have a debate on that.
When you develop a model, when you don't know what your distribution is or you don't have data, you always use a triangular distribution.
With the parameter calibration you want to minimize the error between your data and your model. The function you want to minimize depends on the distribution you have on your data.
To know what is the distribution of your data, you can use a distribution fitting technique such as cullen and frey graph... but it seems that you already have the distribution

Related

How to prove arrival rate follows Exponential Distributions?

I'm studying Anylogic. I'm curious about something.
Some people explain that arrival rate follows Exponential Distribution.
I wanna know 'How can prove that?'
Any kind guidance from you would be very helpful and much appreciated.
Thank you so much.
The arrival rate doesn't follow an exponential distribution, it follows a poisson distribution, so there's nothing to prove on that regard.
What follows an exponential distribution is the inter-arrival time between agents.
To prove that this thing actually follows a particular distribution, you can use one of the many distribution fitting techniques out there, my favorite and the one is the Cullen and Frey Graph. You can see an answer about it here:
https://stats.stackexchange.com/questions/333495/fitting-a-probability-distribution-and-understanding-the-cullen-and-frey-graph
You can also check the wikipedia page on distribution fitting:
https://en.wikipedia.org/wiki/Probability_distribution_fitting
Have in mind that distribution fitting is kinda an art, and no technique gives you the correct distribution, but maybe a good enough approximation of a distribution. But in this case it should be quite easy.
You can't really prove that a distribution fits the data though, you can just have maybe an error estimation when you compare the distribution function with the actual data, and you can have a confidence interval for that... I'm not sure if that's what you want.
not exactly sure what you mean by "prove" that it is exponential... But anyway, it is not "some people" that explain that, it is actually mentioned in AnyLogic help under the "Source" topic as follows:
Rate - agents are generated at the specified arrival rate (which is
equivalent to exponentially distributed interarrival time with mean =
1/rate).
What you can do is collect the interval time between arrivals and plot that distribution to see that it actually looks like an exponential distribution.
To do that:
Create a typical DES process (e.g. source, queue, delay, sink)
Set the arrival type to rate and specify for example 1 per hour
Create a variable in main called "prevTime"
Create a histogram data element called "data"
In the "On exit" of the source write the following code:
data.add(time() - prevTime);
prevTime = time();
Look at the plot of the histogram and its mean.

Is AnyLogic's arrival rate a Poisson distribution?

I am trying to understand the best practices regarding AnyLogic's source arrival rates. I know that Exponential and Poisson are two different probability distributions. When using "Arrival Rate" in AnyLogic and choosing a rate of 10/hour for example, does this generate 10 agents per hour exponentially or according to a Poisson distribution or is it the same thing?
I really need guidance on understanding the best practices in this matter. To simplify the question, if I have an arrival rate of 10/hour following a Poisson distribution, what is the right way to model that in AnyLogic?
Many thanks!
In any source in AnyLogic, if you choose a rate, it will automatically be poisson where your rate will be the lambda parameter of your poisson distribution... this means that in average you will get lambda agents per time unit generated
The exponential distribution is equivalent to the poisson distribution, except that it takes into consideration the time between each arrival instead. (this means that you need to use arrivals defined by inter-arrival time in your source, otherwise it wouldn't make much sense)
poisson(lambda) arrivals per time unit is equivalent to exponential(lambda) time units per arrival, it doesn't really matter which one you use

Looking for a principle to determine how to choose the number of intervals in Dymola

There is an option to set the "Number of intervals" during the simulation in Dymola, but I am not sure how to choose the intervals in a real model.
So I did some tests, Here are my conclusions and questions:
The number of intervals shouldn't be too small, cause when it is too small, the simulation result could deviate from the real value.
So I set the number of intervals above 500 always, it seems working fine right now, but I am not sure if I should increase it.
When using a larger number of intervals, the simulation time could be longer, so maybe I could decrease it.
In short, I am looking for a principle to determine how to choose the number of intervals.
The intervals are just the ones for the plot window not for the simulation.
If you chose 500 you will get 500 points plotted with linear interpolation. The actual stepsize for simulation is chosen by the DASSL-Integerator to ensure stability. The tolerance option can influence that behaviour. If you choose another solver you can even set fixed number of iterator steps, but i would strongly recommend leaving that decision to the solvers.

Theory behind ARMA and Running Average filter and are there any alternative algorithms for calculating distance from RSSI of signal?

I can see that the Android Bacon Library features two algorithms for measuring distance: the running average filter and the ARMA filter.
How are these related to the library's implementation (apart from using the filter's formula)?
Where can I find some background information about these that explains the theory behind it?
Are there any known alternative algorithms that can be studied and tried out for measuring the distance?
There are two basic steps to giving a distance estimate on BLE beacons.
Collect RSSI samples
Convert RSSI samples to a distance estimate.
Both of these steps have different possible algorithms. The ARMA and Running Average filters are two different algorithms used for collecting the RSSI samples.
Understand that beacon send out packets at a periodic rate, typically at 1-10 times per second. Each of these packets, when received by the phone will have its own signal level measurement called RSSI. Because of radio noise and measurement error, there is a large amount of variance on each RSSI sample which can lead to big swings in distance estimates. So typically you want to take a number of RSSI samples and average them together to reduce this error.
The running average algorithm simply takes 20 seconds worth of samples (by default, the time period is configurable), throws out the top and bottom 10 percent of the RSSI readings and takes the mean of the remainder. This is similar to how iOS averages samples, so it is the default algoritm for the library for cross-platform compatibility reasons. But it has the disadvantage that the distance estimate lags behind, telling you where the phone is relative to the beacon an average of 10 seconds ago. This may be inappropriate for use cases where the phone is moving relative to the beacon.
The ARMA (Autoregressive Moving Average) algorithm statistically weights the more recent samples more heavily that the older samples, leading to less lag in the distance estimates. But its behavior can be a bit indeterminate and is subject to more varying performance in different radio conditions.
Which algorithm is right for you depends on your use case. Testing both to see which performs better for you is generally the best approach. While there are other possible algorithms for data collection, these are the only two built in to the library. Since it is open source, you are welcome to create your own and submit them as a pull request.
For step 2, there are also a number of possible algorithms. The two most common are a curve fitted formula and a path loss formula. The curve fitted formula is the library default and the path loss alternative is available only in a branch of the library under development. You are welcome to use the latter, but it requires building the library from source. Again, as an open source library you are welcome and encouraged to develop your own alternative algorithms.

Neural Net - Selecting Data For Each Mini Batch

Possibly an ANN 101 question regarding minim batch processing. Google didn't seem to have the answer. A search here didn't yield anything either. My guess is there's a book somewhere that says, "do it this way!" and I just haven't read that book.
I'm coding a neural net in Python (not that the language matters). I'm attempting to add mini-batch updates instead of full batch. Is it necessary to select each observation once for each epoch? Mini-batches would be data values 1:10, 11:20, 21:30, etc. so that all observations are used, and they are all used once.
Or is it correct to select the mini batch randomly from the training data set based on a probability? The result being that each observation may be used once, multiple times, or not at all in any given epoch. For 20 mini-batches per epoch, each data element would be given a 5% chance of being selected for any given mini-batch. Mini batches would be randomly selected and random in size but approximately 1 of every 20 data points would be included in each of 20 mini batches with no guarantee of selection.
Some tips regarding mini-batch training:
Shuffle your samples before every epoch
The reason is the same as why you shuffle the samples in online training: Otherwise the network might simply memorize the order in which you feed the samples.
Use a fixed batch size for every batch and for every epoch
There is probably also a statistical reason, but it simplifies the implementation as it enables you to use fast implementations of matrix multiplications for your calculations. (e.g. BLAS)
Adapt your learning rate to the batch size
For larger batches you'll have to use a smaller learning rate, otherwise the ANN tends to converge towards a sub-optimal minimum. I always scaled my learning rates by 1/sqrt(n), where n is the batch size. Please note that this is just an empirical value from experiments.
Your first guess is correct.
Just randomize your dataset first.
Then for (say) a 20 mini-batch. Use: 1-20, then 21-40, etc...
So, all your dataset will be used.
Ben don't say that the data set are only used once. You normally need to do multiple epochs on all the dataset for your network to learn properly.
Mini-batch is primarily use to speed up the learning process.