Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 51

Modeling Photoshoot Flow: Identifying Bottlenecks with DES

Recommended resources

In our last lesson, we explored Markov Chain Monte Carlo (MCMC) as a method for inference—a way to learn the posterior distribution of unknown parameters from sparse data. We are now shifting from the realm of statistical inference to dynamic systems analysis. While MCMC helps us answer "What do we know?", the topic of today's lesson, Discrete-Event Simulation (DES), helps us answer "What would happen if?".

Your learning outcome for this session is to develop a Discrete Event Simulation (DES) model to analyze the flow of outfit-pose setups through the photoshoot process and identify bottlenecks. This technique is a cornerstone of operations research for modeling and improving complex workflows, making it a natural extension of your existing expertise. We will move from theory to a conceptual model of your photoshoot scenario, focusing on how to represent the system, model its dynamics, and use the output to diagnose inefficiencies.

What is Discrete-Event Simulation?

At its core, DES is a method for modeling a system that changes over time, but where we only care about the moments of change. Instead of tracking every continuous fluctuation, we jump from one "event" to the next. For a photoshoot, we don't need to model the camera's shutter speed in microseconds; we care about events like "Makeup complete," "Pose A begins," and "Outfit change finished."

The following video from MATLAB provides an excellent introduction to this concept, using an elevator system as an example. It clearly illustrates the contrast between continuous simulation and the event-based abstraction used in DES.

Understanding Discrete Event Simulation, Part 1: What Is Discrete Event Simulation

This video introduces the fundamental idea of DES, contrasting it with continuous simulation and showing how to abstract a real-world system into a series of discrete events.

Please watch from the beginning to the explanation of the event calendar. Pay close attention to: How a complex system (an elevator) is simplified by focusing on events relevant to the study's objective (passenger traffic, not motor physics). The graphical comparison between a continuous representation and a discrete-event state change diagram.

To formalize this, let's turn to a foundational text in the field. The key distinction is between systems where state variables change continuously (like water in a reservoir) and those where they change at specific points in time (like the number of clients in your studio). The photoshoot workflow falls squarely in the latter category.

PART ONE Introduction to Discrete-Event System Simulation

This reading from the classic textbook by Banks, Carson, Nelson, and Nicol formally defines discrete and continuous systems.

In Chapter 1, please read the section titled Discrete and Continuous Systems. You can find it by searching for the heading. It starts with the definitions and includes two helpful diagrams illustrating the concept.

The Anatomy of a DES Model

To build a simulation, we need a consistent set of components. These are the building blocks we'll use to represent the photoshoot process. Your background in OR and queueing theory will make these concepts very familiar.

  • System State: A collection of variables that describe the system at any given moment. For the photoshoot, this could be represented as a vector: (Number of setups waiting for styling, Stylist status [busy/idle], Number of setups waiting for shooting, Photographer status [busy/idle]).
  • Entities: The "things" that flow through the system. In our case, these are not the models or photographers, but the individual outfit-pose setups that need to be completed.
  • Attributes: Properties of an entity. An Outfit-Pose Setup entity might have attributes like outfit_ID, pose_complexity (which could influence service time), and arrival_time (the time it entered the process).
  • Resources: Components with limited capacity that entities need to perform activities. The key resources in the photoshoot are the Photographer, the Stylist, and perhaps physical resources like the Main Studio Space or Makeup Station.
  • Activities: Processes that take a known amount of time. Examples include Styling Time (e.g., exponentially distributed with a mean of 15 minutes) and Shooting Time (e.g., a triangular distribution based on pose complexity). An activity represents an unconditional wait.
  • Queues: Where entities wait when a required resource is busy. We will have a Styling Queue for setups waiting for the stylist and a Shooting Queue for styled setups waiting for the photographer.
  • Events: Instantaneous occurrences that change the state of the system. Key events would be Setup_Arrival, Styling_Complete, and Shooting_Complete.

This structure allows us to formalize the workflow.

PART ONE Introduction to Discrete-Event System Simulation

This reading provides the formal definitions for the core components of a DES model.

In Chapter 1, read the section Components of a System (beginning here). Then, jump to Chapter 3 and read the more detailed definitions in the section Concepts in Discrete-Event Simulation (up to the clock definition). This will solidify the precise meaning of terms like entity, event, activity, and delay.

Visualizing the Photoshoot Workflow

Before implementing a model, it's crucial to have a clear conceptual map. An activity diagram is a simple and powerful tool for this. It shows the journey of an entity through the system, including its interactions with queues and resources.

The following resource explains how to model a simple drive-through pharmacy. This system is a direct analogue to our photoshoot:

  • Pharmacy Customer -> Outfit-Pose Setup (Entity)
  • Pharmacist -> Photographer/Stylist (Resource)
  • Waiting Line -> Styling Queue / Shooting Queue

2.6 Modeling a Simple Discrete-Event Dynamic System

This online book chapter provides a clear, practical guide to conceptual modeling using an activity diagram for a pharmacy system.

Please read the section Modeling the System. Focus on how the author breaks down the problem into entities, resources, and process flows. Pay special attention to the Activity diagram (Figure 2.29 in the text) and how it visually represents the sequence: queue -> seize resource -> activity -> release resource -> exit.

Now, try to sketch a similar activity diagram for the boudoir photoshoot. Assume a simple linear workflow:

  1. An Outfit-Pose Setup entity is created.
  2. It waits in the Styling Queue.
  3. It seizes the Stylist resource.
  4. It undergoes the Styling activity.
  5. It releases the Stylist resource.
  6. It waits in the Shooting Queue.
  7. It seizes the Photographer resource.
  8. It undergoes the Shooting activity.
  9. It releases the Photographer resource.
  10. The entity is disposed (leaves the system).

This diagram will be the blueprint for our simulation model.

How a DES Model Runs: The Time-Advance Algorithm

So how does the simulation actually progress from one event to another? The engine driving a DES is the event-scheduling/time-advance algorithm. It works with two key components:

  1. Simulation Clock: A variable that holds the current simulated time.
  2. Future Event List (FEL): An ordered list of all events scheduled to happen in the future, sorted by time. The event at the top of the list is the next thing that will happen.

The algorithm is a simple, powerful loop:

  1. Remove the imminent event from the top of the FEL.
  2. Advance the simulation clock to the time of this event.
  3. Execute the event, changing the system state accordingly.
  4. As a consequence of the event, new future events may be generated and scheduled (i.e., added to the FEL in their correct time-ordered position).
  5. Repeat until a stopping condition is met.

For example, when an Outfit-Pose Setup entity arrives at the photographer (an Arrival_at_Shooting_Queue event), the logic checks if the Photographer resource is idle. If so, it seizes the resource and schedules a new Shooting_Complete event on the FEL at current_time + shooting_duration.

PART ONE Introduction to Discrete-Event System Simulation

This text explains the event-scheduling algorithm in detail and provides a manual walk-through.

Please read section 3.1.1, The Event-Scheduling/Time-Advance Algorithm (available here). This explains the mechanics of the FEL and the clock. Then, to see it in action, review section 3.1.3 and the Single-Channel Queue example (in this section). Follow the first few rows of the simulation table (Table 3.1) to see how the clock advances and the FEL changes with each event.

From Conceptual Model to Implementation

With our conceptual model and an understanding of the simulation engine, we can think about implementation. Modern DES frameworks are often "process-based," which aligns perfectly with the activity diagram we sketched. In these frameworks, you define the lifecycle of an entity as a process, and the framework handles the underlying event scheduling automatically.

SimPy is a popular Python library for this. The following video gives a great overview. The example of modeling conference attendees is particularly relevant. Attendees are entities, and the buffet is a shared, limited resource. The simulation reveals a bottleneck at the buffet, causing some attendees to go hungry and consequently gain less knowledge. This is exactly what we want to do for the photoshoot: find the resource constraints that create queues and slow down the process.

Event discrete simulation with SimPy

This presentation on the SimPy framework demonstrates a process-based approach to DES and shows how to model resource contention to find bottlenecks.

Watch the following segments: The introduction, which explains the process-based approach. The discussion on shared resources, which introduces concepts like Resource (our Photographer/Stylist), Store, and Container. The conference attendee example. This is a perfect illustration of our goal. Notice how the limited buffet resource (capacity=1) creates a queue and directly impacts the performance metric (knowledge_gain) for some entities (attendees).

In a tool like Arena (or SimPy), we would translate our activity diagram directly:

  1. CREATE module: Generates the Outfit-Pose Setup entities according to some arrival pattern (e.g., all 20 setups are created at time 0).
  2. PROCESS module (Styling): Models the sequence of seizing the Stylist resource, delaying for the styling activity time, and releasing the resource. This module has an internal queue.
  3. PROCESS module (Shooting): Models seizing the Photographer, delaying for the shooting activity, and releasing the resource. This also has a queue.
  4. DISPOSE module: Removes the entity from the simulation after it has completed its lifecycle.

Identifying Bottlenecks Through Analysis

After running the simulation for a specified duration (e.g., until all 20 setups are complete), the software provides performance metrics. To identify bottlenecks, you would look for:

  • High Resource Utilization: Is the photographer busy 99% of the time while the stylist is only busy 40%? This points to the photographer as the bottleneck.
  • Long Queue Times: What is the average time a setup spends waiting in the Shooting Queue versus the Styling Queue? A significantly longer wait time for the photographer is a clear indicator of a bottleneck.
  • Large Number of Entities in Queue: Does the queue for the photographer frequently build up to 5 or 6 setups? This visualizes the bottleneck in action.

By analyzing these outputs, you can answer "what-if" questions. What if we hire a second photographer (increase resource capacity)? What if we buy a tool that speeds up styling (decrease activity time)? Running the simulation with these new parameters will predict the impact on the overall process flow.

2.6 Modeling a Simple Discrete-Event Dynamic System

This section shows what the output of a DES model looks like and how to interpret it.

Please read the final section, Analyze the Results. Notice the key metrics reported: average waiting time, resource utilization, and queue length. These are the primary indicators you would use to diagnose bottlenecks in the photoshoot workflow.

Conclusion

Today we have explored Discrete-Event Simulation as a powerful tool for analyzing dynamic systems. We've seen that by abstracting a complex process into a sequence of events affecting entities, resources, and queues, we can build a model that mimics real-world workflow dynamics.

Key Takeaways:

  • DES models systems by advancing a clock between discrete events, ignoring the time in between. This makes it efficient for analyzing process flows.
  • The core components of a DES model are entities that flow through the system, resources they use, activities that take time, and queues where they wait.
  • The event-scheduling algorithm, using a Future Event List (FEL), is the underlying engine that ensures events are processed in chronological order.
  • By analyzing output statistics like resource utilization and queue wait times, we can identify bottlenecks and test potential system improvements.

In our next lesson, we will move to another simulation paradigm: Agent-Based Modeling (ABM). While DES focuses on a top-down view of process flow, ABM takes a bottom-up approach, modeling the autonomous behavior of individual agents and observing the complex, emergent patterns that arise from their interactions. This will be ideal for modeling the social dynamics of the hotwife and her bull.