## Tuesday, November 10, 2015

### I hope you find this blog enjoyable and helpful. Support it with a small donation.

I've been doing some more work on my discrete event simulator, or to be more accurate, the supporting functions that help to analyse the results.  In my previous post I described a basic stock management situation that can be modelled.  I'll continue to use that model here as it's simple to understand and helps illustrate the features I've added.

To bring you up to speed, the simulation models a 24 hour, 7 day a week business that gets deliveries at 1 am and sells items all day.  It's not realistic but it's a starting point.  The main problem with it is the discrete random nature of the events.  This can be seen in the week long simulation below from the last post.  It's possible to identify trends and events, but it offers no insight into how likely these events are to occur.

 Original One Week Simulation

Getting data about the likelihood of events occurring can be accomplished by running the simulation for a longer time period and then comparing smaller sections of the simulation.  In my case I ran the simulation for 200 weeks, broke the data up into weeks, and then performed analysis on those multiple trials, just like a Monte Carlo simulation.  These results can be seen below.

The graph illustrates the exact same model, but instead of one trial, the model is essentially run 200 times.  This allows percentiles for the simulation to be generated.  In this case 0, 10, 50, 90, 100.  To put this into more understandable terms, in the graph below, 0% of the simulations predicted stock levels less than the dark blue line, 10% predicted levels less than the green line, 50% predicted levels less than the red line, 90% predicted levels less than the light blue line, and 100% of the simulations predict levels less than the purple line.

 A monte carlo analysis of a discrete event simulation
This kind of analysis allows sensible measured conversations about stock levels to take place.  All to often predictions are made that don't allow nuance and can cause problems.  For example, instead of saying "I reckon we'll run out of stock by 1pm"  we can now say "There's a 40% chance we'll run out by 1 pm".  Everyone can take that on board and take appropriate action, it may be a 40% chance is acceptable as there may be some other more urgent matter to take care of.

I'm anthropomorphising the conversation, but in reality I see this as a way for computers to compare and prioritise tasks.

You may have noticed a problem with what I've described.  The original data from the discrete event simulator isn't a regularly sampled data set.  A customer may come in 10 minutes after the last one and then you won't see another for an hour.  To perform the Monte Carlo simulation the data needs to be resampled with a regular timebase.  In my case I've choose to sample the data every 5 minutes.

This is done with a kind of zero order hold.  The process to determine the value at a specific time is straight forward, if an event occurs at this time the new data point will be the value after the event.  If there is no event, the data point will be the value after the last event.  If there is no previous event the first one is used.

The image below illustrates the initial data set of (1, 1), (5, 2), (10, 3), (11, 4), (12, 5), (20 , 6).  These are marked with blue crosses.  The red line shows how this data is resampled for different points.  The black bars show the result of resampling the data at -10, 1, 2, 10 and 30.  The results are 1, 1, 1, 3, and 6 respectively.  I've chosen to resample the data at 5 random points, but if performed at regular intervals the information is ready to be fed to the Monte Carlo analyser.
 Resampling a data set
To give a usage example I've folded the entire simulation into a period of one day.  That means there are 1400 days sampled every 5 minutes simulated and compared in the image below.  If I had concerns about the stock levels at 8:50 pm (sample 250), I could look at this and say that I'm very confident that there will be stock, if fact there should be about 30 to 50 items available.

 The simulation folded into a single day
In the simulation below I've increased the sales rate so a different question can be asked.  If customers complain about out of stocks you can look at this and say that supplies will run out somewhere between 7:30 am and 3:50 pm (90 and 190), but most likely at 10:50 am (130).  This then allows you to take action, such as increasing the order size.

 Increase rate of purchase indicates likely stock exhaustion points
It's all a bit simplistic at the moment, but it's getting there.  What I'm really aiming to show is the complex interaction of seemingly unrelated variables.
 Get the code
.