Our goal for this project was to use industrial engineering tools for a real-life application, specifically one that is not limited to the typical industrial engineering problems we usually encounter.
Team Members:
Project Summary
Music is everywhere. For our final project we wanted to go with a less traditional model. In class we saw many different transportation, manufacturing, and scheduling problems that revolved primarily around industrial engineering processes. We decided to take a different approach while still structuring a scheduling model. We wanted to create a problem that had a real life application without being exclusive to industrial engineering. We decided to take a personal playlist with about 800 songs and select an optimized subset for listeners based on popularity. Getting spotify data from the playlist allowed us to get things like a popularity score, album name, song name, artist, etc. Taking this information, we created a model that would make 8, one hour long playlists that would work similarly to a radio station. Again this is not the normal industrial engineering scenario, but this project was a way for us to show how industrial engineering tools can be used in everyday life.
Model Formulation
Our objective function was to maximize the total popularity score of the songs played across all 8 hours. Each hour had to have at least ten songs, with songs being played for at least 55 minutes out of the total hour. No song can be repeated across all 8 hours, and each hour can’t play more than 2 songs from the same album, and 4 songs from the same artist.
Solution & Results:
We chose to make many different changes to our model to improve optimization. Filtering the data to only include songs with a popularity score of 50 or greater gave the model a chance to run faster. This choice, however, took a significant chunk of our data. Now our model only runs through 498 songs instead of the original 734. While this helped us run the model, there was still the issue of running the model to optimal capacity. Our computers do not have the capacity to run our model to completion because the model needs to check almost 4,000 different variables within our data. We used hashmaps to give quick access to the results but this can only help so much with our run time. Using the lower bound of 50 on popularity and hash maps were the best ways we could run our model to get close to the optimal popularity of our playlists, but the analysis below will show the way our results are truly affected by these factors (we have also provided our printed results in a separate pdf because it is very large).
Full song model:
We started with small increases in run time limits between a minute and an hour to look at the improvement of our model’s solution as time went on. The best bound that the solver could find was 11224.007 for total popularity, but checking all of the feasible solutions close to that took the solver too long. You can see the improvements in the objective value over time as it starts at 11156 and moves up to 11205 by the time the compiler hits the 60 minute mark. Ultimately, we ended with a GAP of 0.17% which is usually acceptable in industry, so we kept our best solution from our 60 minute run time limit. When testing the model with all songs included in the decision variable pool, the upper bound found by the solver was higher than our official model. This is consistent with our prediction that the solver would be able to hone in on the actual optimal solution faster using the limited variable model. The GAP also starts higher in the 2nd model at 1 minute run time than it does in the first, suggesting there is more variability in solutions being found (since the solver has to test more variables).
Conclusions & Recommendations:
As stated in our introduction, this problem was meant to mimic a radio station. With our model, sensitivity analysis, and results, we have come to a somewhat underwhelming conclusion. Even though our model produced quality results, the run time was a significant limitation. This application for practical use is simply not worth it. The computing power required to optimize this data took multiple hours, and there are many more efficient ways to perform this task. Decisions like these need to be made in seconds not hours and the run time only increases as the data increases. Creating a heuristic or greedy model would be a more practical approach, however these approaches sacrifice optimality, unlike our current model.