Hubbry Logo
search
logo
Discrete-event simulation avatar
Discrete-event simulation
Discrete-event simulation
current hub
D

Discrete-event simulation

logo
Community Hub0 Subscribers
Read side by side
Discrete-event simulation
View on Wikipedia
from Wikipedia

A discrete-event simulation (DES) models the operation of a system as a (discrete) sequence of events in time. Each event occurs at a particular instant in time and marks a change of state in the system.[1] Between consecutive events, no change in the system is assumed to occur; thus the simulation time can directly jump to the occurrence time of the next event, which is called next-event time progression.

In addition to next-event time progression, there is also an alternative approach, called incremental time progression, where time is broken up into small time slices and the system state is updated according to the set of events/activities happening in the time slice.[2] Because not every time slice has to be simulated, a next-event time simulation can typically run faster than a corresponding incremental time simulation.

Both forms of DES contrast with continuous simulation in which the system state is changed continuously over time on the basis of a set of differential equations defining the rates of change for state variables.

In the past, these three types of simulation have also been referred to, respectively, as: event scheduling simulation, activity scanning simulation, and process interaction simulation. It can also be noted that there are similarities between the implementation of the event queue in event scheduling, and the scheduling queue used in operating systems.

Example

[edit]

A common exercise in learning how to build discrete-event simulations is to model a queueing system, such as customers arriving at a bank teller to be served by a clerk. In this example, the system objects are customer and teller, while the system events are customer-arrival, service-start and service-end. Each of these events comes with its own dynamics defined by the following event routines:

  1. When a customer-arrival event occurs, the state variable queue-length is incremented by 1, and if the state variable teller-status has the value "available", a service-start follow-up event is scheduled to happen without any delay, such that the newly arrived customer will be served immediately.
  2. When a service-start event occurs, the state variable teller-status is set to "busy" and a service-end follow-up event is scheduled with a delay (obtained from sampling a service-time random variable).
  3. When a service-end event occurs, the state variable queue-length is decremented by 1 (representing the customer's departure). If the state variable queue-length is still greater than zero, a Service-Start follow-up event is scheduled to happen without any delay. Otherwise, the state variable teller-status is set to "available".

The random variables that need to be characterized to model this system stochastically are the interarrival-time for recurrent customer-arrival events and the service-time for the delays of service-end events.

Components

[edit]

State

[edit]

A system state is a set of variables that captures the salient properties of the system to be studied. The state trajectory over time S(t) can be mathematically represented by a step function whose value can change whenever an event occurs.

Clock

[edit]

The simulation must keep track of the current simulation time, in whatever measurement units are suitable for the system being modeled. In discrete-event simulations, as opposed to continuous simulations, time 'hops' because events are instantaneous – the clock skips to the next event start time as the simulation proceeds.

Events list

[edit]
"Future event list" redirects here. For lists of future events, see Timelines of the future.

The simulation maintains at least one list of simulation events. This is sometimes called the pending event set because it lists events that are pending as a result of previously simulated event but have yet to be simulated themselves. An event is described by the time at which it occurs and a type, indicating the code that will be used to simulate that event. It is common for the event code to be parametrized, in which case, the event description also contains parameters to the event code.[citation needed] The event list is also referred to as the future event list (FEL) or future event set (FES).[3][4][5][6]

When events are instantaneous, activities that extend over time are modeled as sequences of events. Some simulation frameworks allow the time of an event to be specified as an interval, giving the start time and the end time of each event.[citation needed]

Single-threaded simulation engines based on instantaneous events have just one current event. In contrast, multi-threaded simulation engines and simulation engines supporting an interval-based event model may have multiple current events. In both cases, there are significant problems with synchronization between current events.[citation needed]

The pending event set is typically organized as a priority queue, sorted by event time.[7] That is, regardless of the order in which events are added to the event set, they are removed in strictly chronological order. Various priority queue implementations have been studied in the context of discrete event simulation;[8] alternatives studied have included splay trees, skip lists, calendar queues,[9] and ladder queues.[10][11] On massively-parallel machines, such as multi-core or many-core CPUs, the pending event set can be implemented by relying on non-blocking algorithms, in order to reduce the cost of synchronization among the concurrent threads.[12][13]

Typically, events are scheduled dynamically as the simulation proceeds. For example, in the bank example noted above, the event CUSTOMER-ARRIVAL at time t would, if the CUSTOMER_QUEUE was empty and TELLER was idle, include the creation of the subsequent event CUSTOMER-DEPARTURE to occur at time t+s, where s is a number generated from the SERVICE-TIME distribution.[citation needed]

Random-number generators

[edit]

The simulation needs to generate random variables of various kinds, depending on the system model. This is accomplished by one or more Pseudorandom number generators. The use of pseudo-random numbers as opposed to true random numbers is a benefit should a simulation need a rerun with exactly the same behavior.

One of the problems with the random number distributions used in discrete-event simulation is that the steady-state distributions of event times may not be known in advance. As a result, the initial set of events placed into the pending event set will not have arrival times representative of the steady-state distribution. This problem is typically solved by bootstrapping the simulation model. Only a limited effort is made to assign realistic times to the initial set of pending events. These events, however, schedule additional events, and with time, the distribution of event times approaches its steady state. This is called bootstrapping the simulation model. In gathering statistics from the running model, it is important to either disregard events that occur before the steady state is reached or to run the simulation for long enough that the bootstrapping behavior is overwhelmed by steady-state behavior. (This use of the term bootstrapping can be contrasted with its use in both statistics and computing).

Statistics

[edit]

The simulation typically keeps track of the system's statistics, which quantify the aspects of interest. In the bank example, it is of interest to track the mean waiting times. In a simulation model, performance metrics are not analytically derived from probability distributions, but rather as averages over replications, that is different runs of the model. Confidence intervals are usually constructed to help assess the quality of the output.

Ending condition

[edit]

Because events are bootstrapped, theoretically a discrete-event simulation could run forever. So the simulation designer must decide when the simulation will end. Typical choices are "at time t" or "after processing n number of events" or, more generally, "when statistical measure X reaches the value x".

Three-phased approach

[edit]

Pidd (1998) has proposed the three-phased approach to discrete event simulation. In this approach, the first phase is to jump to the next chronological event. The second phase is to execute all events that unconditionally occur at that time (these are called B-events). The third phase is to execute all events that conditionally occur at that time (these are called C-events). The three phase approach is a refinement of the event-based approach in which simultaneous events are ordered so as to make the most efficient use of computer resources. The three-phase approach is used by a number of commercial simulation software packages, but from the user's point of view, the specifics of the underlying simulation method are generally hidden.

Common uses

[edit]

Diagnosing process issues

[edit]

Simulation approaches are particularly well equipped to help users diagnose issues in complex environments. The theory of constraints illustrates the importance of understanding bottlenecks in a system. Identifying and removing bottlenecks allows improving processes and the overall system. For instance, in manufacturing enterprises bottlenecks may be created by excess inventory, overproduction, variability in processes and variability in routing or sequencing. By accurately documenting the system with the help of a simulation model it is possible to gain a bird’s eye view of the entire system.

A working model of a system allows management to understand performance drivers. A simulation can be built to include any number of performance indicators such as worker utilization, on-time delivery rate, scrap rate, cash cycles, and so on.

Hospital applications

[edit]

An operating theater is generally shared between several surgical disciplines. Through better understanding the nature of these procedures it may be possible to increase the patient throughput.[14] Example: If a heart surgery takes on average four hours, changing an operating room schedule from eight available hours to nine will not increase patient throughput. On the other hand, if a hernia procedure takes on average twenty minutes providing an extra hour may also not yield any increased throughput if the capacity and average time spent in the recovery room is not considered.

Lab test performance improvement ideas

[edit]

Many systems improvement ideas are built on sound principles, proven methodologies (Lean, Six Sigma, TQM, etc.) yet fail to improve the overall system. A simulation model allows the user to understand and test a performance improvement idea in the context of the overall system.

Evaluating capital investment decisions

[edit]
See also: Monte Carlo methods in finance, Corporate finance § Capital investment decisions, and Corporate finance § Quantifying uncertainty

Simulation modeling is commonly used to model potential investments. Through modeling investments decision-makers can make informed decisions and evaluate potential alternatives.

Network simulators

[edit]
Main article: Network simulation

Discrete event simulation is used in computer network to simulate new protocols, different system architectures (distributed, hierarchical, centralised, P2P) before actual deployment. It is possible to define different evaluation metrics, such as service time, bandwidth, dropped packets, resource consumption, and so on.

See also

[edit]

System modeling approaches:

Computational techniques:

Software:

Disciplines:

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Discrete-event simulation

View on Grokipedia
from Grokipedia
Discrete-event simulation (DES) is a computational modeling technique that represents the operation of a system as a chronological sequence of discrete events, each occurring at a specific instant in time and causing an instantaneous change in the system's state variables, with no evolution between events.[1] This approach contrasts with continuous simulation by focusing on event-driven dynamics rather than smooth time progression, making it suitable for systems where changes are sporadic and identifiable, such as queues or manufacturing processes.[2] Key components of DES include the simulation clock, which advances discretely to the time of the next event; an event list, typically implemented as a priority queue to manage pending events ordered by occurrence time; state variables that capture the system's configuration; and input parameters that can be deterministic or stochastic to reflect real-world variability.[1] The simulation proceeds by processing events in order, updating states and potentially scheduling future events, while collecting performance metrics such as average waiting times, throughput, or resource utilization to evaluate system behavior.[1] DES employs several modeling paradigms, including event-oriented approaches that directly handle event execution for efficiency, activity-oriented methods that track entity movements step-by-step, and process-oriented views that model system components as interacting processes or threads.[2] It is widely applied across domains, including manufacturing and logistics for optimizing production lines, healthcare for analyzing patient flows and resource allocation, computer networks for traffic modeling, and military simulations for scenario testing.[3] These applications enable "what-if" analyses to inform decision-making, identify bottlenecks, and assess policy impacts without real-world experimentation.[4]

Illustrative Example

A simple example of DES is simulating a single-server queue, such as a bank teller line. Events include customer arrivals and service completions. Upon arrival, if the server is free, service begins immediately; otherwise, the customer joins the queue. The simulation clock jumps to the next event time (e.g., next arrival or service end), updating the queue length and server status accordingly. This models waiting times and queue buildup without simulating idle moments between events.[2]

Introduction

Definition and Principles

Discrete-event simulation is a computational modeling technique used to represent the behavior of complex systems where the state variables change instantaneously only at discrete points in time, known as events, rather than evolving continuously.[5] This approach generates an artificial history of the system by advancing a simulation clock directly from one event to the next, capturing snapshots of the system state at these transition points to estimate performance measures such as throughput or queue lengths.[5] It is particularly suited for stochastic, dynamic systems like manufacturing lines or communication networks, where events (e.g., arrivals or service completions) drive all significant changes.[6] The core principles of discrete-event simulation revolve around event-driven dynamics, where the system's evolution is governed by a schedule of future events managed in chronological order. Upon processing an event, the system state updates instantaneously, and new events may be scheduled probabilistically to account for randomness, such as variable interarrival times.[5] The simulation clock does not increment in fixed steps but jumps to the time of the imminent event, emphasizing logical progression over physical time and enabling efficient modeling of sparse activity periods.[5] This paradigm handles stochastic elements through random number generation for event timing and outcomes, while focusing on discrete state transitions that reflect real-world discontinuities.[6] Unlike continuous simulation, which models systems with smoothly varying variables over time (e.g., fluid flow or population growth using differential equations), discrete-event simulation prioritizes abrupt, event-triggered changes and ignores intervals between events where no state alterations occur.[5] This distinction makes it more efficient for systems with infrequent but impactful events, such as queueing networks, compared to the time-stepped integration required in continuous models.[5] GPSS, developed by Geoffrey Gordon at IBM in the early 1960s and presented in 1961, was a pioneering simulation language that formalized the event-scheduling paradigm and laid the groundwork for modern simulation tools by enabling users to model complex interactions without low-level programming.[7][8]

Illustrative Example

To illustrate the operation of discrete-event simulation, consider a single-server queue modeling customers arriving at a bank teller window, where the only events are customer arrivals and service completions.[9] The system state is defined by the number of customers in the system N(t)N(t), the queue length Q(t)Q(t), and the server status B(t)B(t) (1 if busy, 0 if idle), with the simulation clock tt advancing discretely to the next event time.[9] An event list maintains scheduled future events, such as the next arrival or departure, processed in chronological order using a first-in, first-out queue discipline.[9] The simulation starts at t=0t = 0 with an empty queue (Q(0)=0Q(0) = 0), no customers in the system (N(0)=0N(0) = 0), and the server idle (B(0)=0B(0) = 0).[9] The initial event list schedules the first customer arrival at t=3t = 3 minutes. The clock jumps to this time, triggering the arrival event: customer 1 enters the system (N(3)=1N(3) = 1), joins an empty queue (Q(3)=0Q(3) = 0), and immediately starts service since the server is idle (B(3)=1B(3) = 1), with a service time of 4 minutes, scheduling a departure event at t=7t = 7 (3 + 4). The updated event list now includes the next arrival at t=11t = 11 and the departure at t=7t = 7.[9] The clock advances to t=7t = 7 for the departure event: customer 1 completes service and leaves (N(7)=0N(7) = 0), the server becomes idle (B(7)=0B(7) = 0), and the queue remains empty (Q(7)=0Q(7) = 0). The next event is the arrival of customer 2 at t=11t = 11: the customer enters (N(11)=1N(11) = 1), service starts immediately (B(11)=1B(11) = 1, Q(11)=0Q(11) = 0), with a 4-minute service time scheduling departure at t=15t = 15. Subsequent events build the queue as arrivals cluster. For instance, at t=13t = 13, customer 3 arrives while the server is busy serving customer 2, increasing the queue to Q(13)=1Q(13) = 1 and N(13)=2N(13) = 2; service for customer 3 is scheduled to start at t=15t = 15 upon customer 2's departure. At t=14t = 14, customer 4 arrives, further lengthening the queue to Q(14)=2Q(14) = 2 and N(14)=3N(14) = 3, with service start delayed to t=19t = 19.[9] The simulation continues processing arrivals and departures, with the queue peaking at 3 customers around t=21t = 21 as a cluster of arrivals (customers 5–7) occurs while earlier customers are still being served. Departures then reduce the queue: for example, at t=22t = 22, customer 4 departs after a 5-minute wait, allowing the server to remain busy. The run terminates after customer 7's departure at t=31t = 31, having processed 7 customers (customer 8's arrival at 27 is queued but not fully served in this trace). State updates occur only at event times, avoiding unnecessary computation between events.[9] The following table summarizes the event sequence, state changes, and per-customer metrics for the first seven customers (arrival times: 3, 11, 13, 14, 17, 19, 21; service times: 4, 4, 4, 3, 2, 4, 3 minutes), where AiA_i is arrival time, SiS_i is service start time, DiD_i is departure time, Wi=Si−AiW_i = S_i - A_i is wait time, and Ti=Di−AiT_i = D_i - A_i is time in system.[9]
Event Time ttEvent TypeCustomer IDAiA_iSiS_iDiD_iWiW_iTiT_iN(t)N(t)Q(t)Q(t)B(t)B(t)
3Arrival133704101
7Departure133704000
11Arrival211111504101
13Arrival313151926211
14Arrival414192258321
15Departure211111504211
17Arrival517222457321
19Departure313151926211
19Arrival619242859321
21Arrival7212831710431
22Departure414192258321
24Departure517222457211
27Arrival827--4*-321
28Departure619242859211
31Departure7212831710101
*Partial wait for customer 8 at simulation end. From this run, key performance metrics are computed: the average waiting time in queue is W‾=24/7≈3.43\overline{W} = 24 / 7 \approx 3.43 minutes per customer, the average time in system is T‾=48/7≈6.86\overline{T} = 48 / 7 \approx 6.86 minutes, the time-averaged number in queue is Q‾(t)=28/31≈0.90\overline{Q}(t) = 28 / 31 \approx 0.90 customers, and server utilization is B‾(t)=24/31≈0.77\overline{B}(t) = 24 / 31 \approx 0.77.[9] These results demonstrate how event-driven advances and state updates yield insights into system behavior, such as queue buildup from arrival bursts. In full simulations, arrival and service times would be stochastically generated using random number generators to reflect variability.[9]

Key Components

System State

In discrete-event simulation (DES), the system state is defined as the collection of state variables necessary to describe the condition of the simulated system at any given time. These variables capture essential attributes such as the number of entities in queues, the status of resources, or the positions of objects within the model, providing a complete snapshot of the system's configuration without including time-dependent changes between events.[5][10] State updates in DES occur instantaneously and exclusively at the occurrence of discrete events, with no alterations to the state variables in the intervals between events. For instance, upon execution of an arrival event, the relevant state variable—such as a queue length counter—is incremented by one, while a departure event might decrement it or update a resource availability flag. This event-driven update mechanism ensures that the system state remains constant during inter-event periods, reflecting the piecewise-constant nature of DES models.[1][5] State variables in DES are typically classified into discrete types, which hold integer or categorical values like counts of entities or binary statuses (e.g., idle or busy), and auxiliary variables that serve temporary roles during event processing, such as flags to track ongoing operations or intermediate computations without persisting across events. Discrete variables form the core of the state, enabling efficient representation of countable system elements, whereas auxiliary ones facilitate modular event routines without cluttering the primary state description.[10][5] A representative example of a system state snapshot appears in a manufacturing simulation, where the state might include an array of machine statuses (e.g., {machine1: busy, machine2: idle}) and work-in-progress inventory levels (e.g., buffer1: 5 units, buffer2: 2 units), updated only when events like part arrivals or processing completions occur. This structure allows the state to interact seamlessly with the event list for sequential processing and supports subsequent computation of performance statistics.[1][5]

Simulation Clock

In discrete-event simulation (DES), the simulation clock serves as the primary mechanism for tracking the passage of simulated time, which is advanced only at the instants when events occur, reflecting changes in the system's state. It is typically initialized to zero at the start of the simulation, corresponding to the beginning of the observation period, with the system set to its initial conditions such as an empty queue or idle resources. This clock value represents the current simulated time and is used to sequence events chronologically, ensuring that the simulation captures the logical progression of the modeled system without unnecessary computations during periods of inactivity.[5] The time advancement algorithm operates by setting the clock directly to the scheduled time of the next event, determined as the minimum time from the future event list, thereby leaping forward without interpolating or simulating continuous time flows between events. This next-event time advance mechanism processes the event, updates the system accordingly, and schedules any subsequent events before repeating the cycle. For example, if no events are pending, the clock jumps to the earliest future occurrence, skipping idle intervals efficiently. This approach contrasts with fixed-increment methods by aligning time progression strictly to event occurrences, optimizing computational resources for systems where changes are sporadic.[5] When multiple events are scheduled at the exact same simulated time—known as zero-time events—the clock remains stationary while these events are processed in sequence, often according to predefined priorities, first-in-first-out order, or system-specific rules to maintain logical consistency. This sequential handling ensures that all simultaneous changes, such as an arrival and a departure occurring concurrently, are resolved without advancing the clock until all are addressed, preventing errors in state dependencies.[5] In stochastic DES models, the clock's discontinuous jumps emphasize the logical ordering of events driven by probabilistic interarrival or service times, rather than uniform or incremental time steps, which distinguishes it from time-stepped simulations that advance in regular intervals regardless of activity. This event-oriented progression is particularly suited to modeling systems like queues or manufacturing lines, where time between changes varies and continuous tracking would be inefficient.[5]

Event List

In discrete-event simulation, the event list, often referred to as the future event list (FEL), serves as the central data structure for organizing and accessing all scheduled future events. It maintains a collection of event notices, each specifying the event type (e.g., arrival or departure), the associated time of occurrence, and relevant attributes such as the involved entities or parameters. This structure ensures that the simulation progresses by processing events in chronological order, reflecting the non-continuous nature of the modeled system. Typically implemented as a priority queue, the FEL orders events by increasing simulation time to facilitate rapid identification of the imminent event.[11] Events are inserted into the FEL through scheduling mechanisms, which can be unconditional—such as routinely adding a future arrival event—or conditional, where insertion depends on the current system state, like scheduling a service completion only if a server becomes available. Upon insertion, the event notice is placed in its appropriate position within the priority queue to preserve the time-based ordering. Removal involves extracting the event with the earliest time, which is then executed to update the system; this operation is performed repeatedly to drive the simulation forward. For efficiency, common implementations use binary heaps, where insertion and removal both operate in O(log n) time complexity, with n being the number of events in the list, making them suitable for simulations with moderate to large event volumes.[11][12] The FEL also requires mechanisms for managing dynamic changes, such as cancellations of preempted or invalidated events; this might involve deleting specific notices by searching for matching attributes like entity identifiers, though such operations can be costly if not optimized. When multiple events share the same timestamp, the priority queue resolves ties using secondary criteria, such as event type priority or a first-in-first-out order, to determine the execution sequence. Advanced data structures further enhance management: for instance, the calendar queue organizes events into time-based buckets with linked lists, achieving amortized O(1) time for both insertions and removals by dynamically adjusting bucket widths to balance load, as demonstrated in benchmarks where it outperformed binary search trees by a factor of three for queues of 10,000 events. These efficiency considerations are crucial, as inefficient FEL management can increase overall simulation runtime by up to five times in complex models.[11][13][12]

Random Number Generators

In discrete-event simulation (DES), random number generators are crucial for introducing stochasticity to model uncertainties such as variable arrival times, service durations, or decision outcomes. Uniformly distributed pseudorandom variates, typically in the interval [0,1), serve as the foundation, which are then transformed into random variates following specific probability distributions to simulate real-world variability.[5][14] Pseudorandom numbers are generated using deterministic algorithms that produce sequences indistinguishable from true randomness for practical purposes. A widely used method is the linear congruential generator (LCG), defined by the recursive formula
Xn+1=(aXn+c)mod  m, X_{n+1} = (a X_n + c) \mod m,
where XnX_n is the current state (seed), aa is the multiplier, cc is the increment, and mm is the modulus, all integers with m>0m > 0. The output is normalized as Un=Xn/mU_n = X_n / m to yield a uniform [0,1) variate. To achieve long periods (up to mm), parameters must satisfy conditions such as gcd⁡(c,m)=1\gcd(c, m) = 1 and a−1a - 1 divisible by all prime factors of mm; exemplary choices include m=231−1m = 2^{31} - 1, a=16807a = 16807, and c=0c = 0 for a full period of 231−22^{31} - 2.[15][5] These uniform variates are transformed into desired distributions via methods like the inverse transform sampling. For an exponential distribution with rate λ>0\lambda > 0, used to model inter-arrival or service times, the cumulative distribution function F(x)=1−e−λxF(x) = 1 - e^{-\lambda x} (for x≥0x \geq 0) has inverse F−1(u)=−1λln⁡(1−u)F^{-1}(u) = -\frac{1}{\lambda} \ln(1 - u); thus, generating U∼[Uniform](/page/Uniform)[0,1)U \sim \text{[Uniform](/page/Uniform)}[0,1) and setting the variate as X=−1λln⁡(U)X = -\frac{1}{\lambda} \ln(U) yields an exponential random variable, since 1−U∼Uniform[0,1)1 - U \sim \text{Uniform}[0,1). For distributions without closed-form inverses, the acceptance-rejection method proposes candidates from a simpler distribution and accepts them with probability proportional to the target density over an envelope, ensuring correct sampling at the cost of some rejections.[16][17][5] To support advanced simulation techniques, random number generators often produce multiple independent streams—disjoint subsequences from a base generator, each with its own seed or substream advancement. This allows assigning separate streams to different model components (e.g., arrivals vs. services), facilitating variance reduction methods such as common random numbers, where identical streams across simulation runs or scenarios minimize differences due to randomness rather than system changes. Software libraries like RngStream implement such streams with periods exceeding 21272^{127}, ensuring independence and reproducibility.[18][5]

Statistics Collection

In discrete-event simulation, statistics collection involves gathering data on system performance metrics during the simulation run to evaluate key performance indicators such as throughput, utilization, and queue lengths. These metrics are typically categorized into point estimates, which provide single values like total throughput (the cumulative count of entities completing the system), and interval estimates, which offer averages with associated uncertainty, such as the average queue length computed via time-weighted averages. Time-weighted averages account for the duration each state persists between events, ensuring that longer periods contribute proportionally more to the overall estimate. For instance, queue length averages are derived by integrating the queue size over time, divided by the total simulation time. Collection methods rely on updating accumulators at event occurrences to track these metrics efficiently without continuous monitoring. For example, server busy time is accumulated by adding the time interval (delta time) between a server becoming busy and subsequently idle to a running total whenever a state change event occurs. Counts like throughput are simply incremented each time an entity exits the system. To obtain confidence intervals for these estimates, multiple independent replications of the simulation are performed, allowing computation of the sample mean and standard deviation across runs, which enables statistical inference on the true system parameters. For steady-state simulations, where interest lies in long-run behavior after initial transients fade, statistics collection must address initialization bias by detecting and discarding the warm-up period. Common techniques include discarding a fixed initial portion of the output or using batch means, where the simulation output is divided into non-overlapping batches treated as independent observations to handle positive autocorrelation in the data. The sample mean from batch means is calculated as
Xˉ=1n∑i=1nXi\bar{X} = \frac{1}{n} \sum_{i=1}^n X_i
, where XiX_i is the mean of the ii-th batch and nn is the number of batches, providing an unbiased estimate of the steady-state mean with variance adjusted for batch size. Output analysis further refines these collected statistics, particularly through the replication/deletion approach to mitigate initialization bias in steady-state runs. This method involves running multiple replications, deleting an initial portion (warm-up) from each to remove bias, and then analyzing the remaining data for point and interval estimates using standard statistical procedures like t-intervals. For warm-up determination, Welch's procedure offers a graphical method: it computes moving-time averages from multiple replications and plots them against time, identifying the point where the averages stabilize and separate bands indicate steady-state achievement, typically requiring 5–10 replications for reliable visualization.

Termination Conditions

In discrete-event simulation, termination conditions define the criteria for ending a simulation run, ensuring that sufficient data is collected to meet analytical objectives while avoiding excessive computational resources. These conditions are essential for both terminating simulations, which model systems with a natural end point, and non-terminating (steady-state) simulations, which approximate long-run behavior.[5][10] Common termination conditions rely on fixed thresholds to provide straightforward control. One prevalent approach is to run the simulation until the clock reaches a predetermined time, such as 1000 minutes or 120 months, often implemented by scheduling a dedicated end-simulation event.[5][10] Another is to halt after a specific number of events, for instance, processing 1000 customer arrivals or 3000 job completions, which ties the run length directly to system activity.[5][10] Entity-based conditions extend this by stopping when a target involving system entities is achieved, such as serving 1000 customers or shipping the last item in an inventory model.[5][10] These methods ensure reproducibility but may require preliminary testing to select appropriate thresholds that capture relevant system dynamics without under- or over-sampling. Statistical termination conditions offer a data-driven alternative, allowing runs to adapt based on the precision of output estimates. A simulation may continue until the half-width of a confidence interval for a key performance measure, such as average queue length, falls below a specified value ε (e.g., ε = 2 units at 95% confidence).[5][10] Sequential sampling plans further refine this by incrementally analyzing accumulating data and stopping when statistical criteria are met, such as requiring at least 19 replications for a desired error bound in mean throughput estimates.[5] These approaches, often using methods like the two-stage Bonferroni procedure, prioritize estimate reliability over fixed durations.[5] For steady-state simulations, where the goal is to ignore initial transients and focus on equilibrium behavior, termination requires careful handling to avoid biased results. Pilot runs are commonly used to estimate the necessary run length, identify a warmup period (e.g., discarding the first 2 hours or 10 days of data), and ensure the system reaches statistical steady-state before full data collection begins.[5][10] Techniques like the replication/deletion method involve multiple short runs with data deletion from the start, while batch means analysis divides a single long run (e.g., into 30 batches) to verify independence and steady-state attainment.[5] To prevent infinite loops in event scheduling, especially in steady-state cases, safeguards such as maximum allowable events or clock time are incorporated.[5] Practical implementations often combine multiple conditions for robustness, such as terminating at the minimum of a fixed time (e.g., 720 minutes) or a maximum number of events (e.g., 1000 customers), which mitigates risks like event list overflow in prolonged runs.[5][10] This hybrid strategy, supported by tools like Arena's output analyzer for real-time precision checks, ensures simulations remain efficient and reliable across diverse applications.[5]

Simulation Methodologies

Event-Scheduling Approach

The event-scheduling approach, also known as the next-event protocol, is a core methodology in discrete-event simulation that advances the simulation by sequentially processing the earliest pending event from a future event list (FEL). This method models system dynamics through a sequence of instantaneous events that alter the system state at discrete points in time, without simulating the passage of time between events. Originating in early simulation efforts, it was formalized by K.D. Tocher as an event-oriented paradigm for representing complex systems like queuing networks.[19] The approach emphasizes a global event list to manage all anticipated changes, making it a foundational technique for implementing simulations in languages like GPSS and modern tools such as Arena. The core algorithm begins with initializing the system state variables, setting the simulation clock to zero, and scheduling initial events into the FEL. It then enters a loop where the event notice with the smallest timestamp is removed from the FEL, the clock is advanced to that event's time, and the associated event routine is executed. During execution, the routine updates the system state—such as incrementing counters or reallocating resources—and may schedule additional future events into the FEL based on the outcomes. This cycle repeats until a predefined termination condition, like reaching a maximum number of events or a specific clock time, is satisfied. The algorithm ensures logical consistency by processing events in strict chronological order, handling simultaneous events through tie-breaking rules if necessary.[5] Event execution typically proceeds in structured phases to maintain model integrity: first, pre-execution checks validate the event's applicability given the current state, preventing invalid actions; second, the state is updated to reflect the event's effects, such as a departure reducing queue length; and third, post-execution scheduling occurs, where new events are added unconditionally for predictable future occurrences (e.g., a fixed-interval arrival) or conditionally based on state-dependent logic (e.g., scheduling a service completion only if a server becomes free). These phases allow for modular event routines that encapsulate decision logic and updates. This approach is ideal for modeling systems featuring simple, asynchronous entities with infrequent interactions, accommodating both deterministic events (e.g., scheduled maintenance) and stochastic ones (e.g., random arrivals via probability distributions). It excels in scenarios like single-server queues or inventory systems where event interdependencies are minimal, providing efficient time advancement without unnecessary computations between events.[5] The following pseudocode outlines the basic event-scheduling algorithm: 
Initialize system state
Set clock = 0
Schedule initial events into FEL

While not termination condition:
    next_event = extract minimum from FEL  // earliest timestamp
    If FEL is empty, terminate
    clock = next_event.time
    Execute event routine for next_event  // update state, schedule new events
    Dispose of next_event notice
[20]

Process-Interaction Approach

The process-interaction approach to discrete-event simulation models systems as a collection of individual processes, where entities such as customers, jobs, or transactions interact with resources and each other over time. In this paradigm, entities progress through predefined sequences of activities, often represented as block diagrams or flowcharts, tracing their lifecycles from creation to termination. Key events include entity creation (e.g., arrivals), resource acquisition (seize), delays (e.g., service times), and resource release (e.g., departures), which drive the simulation by advancing the clock and updating system state. This entity-centric view facilitates modeling of dynamic interactions, such as contention for shared resources, making it particularly suitable for systems involving queues and workflows.[5] Central to the approach are process definitions, which outline sequences of activities like queuing, delaying, branching based on conditions, and transferring between processes. Interactions occur through shared elements: facilities represent single-server resources (e.g., a machine that one entity at a time can seize and release), while storages model multi-unit resources or buffers (e.g., inventory or queues holding multiple entities). Entities may preempt resources or use priority rules during contention, with the simulation managing synchronization via mechanisms like locks or conditional waits to ensure realistic behavior. Event types are primarily entity-driven, such as arrivals and departures that alter queue lengths, alongside resource-driven events like seize and release that reflect availability changes; these are scheduled on a future event list, often using high-level constructs from languages like GPSS (General Purpose Simulation System), originally developed in 1961.[5][5] This methodology excels in modeling complex workflows, such as manufacturing lines or service operations, where tracing entity paths reveals bottlenecks and throughput issues more intuitively than a purely event-scheduling view. By abstracting low-level event logic into process flows, it reduces modeling complexity and coding effort, enabling analysts to focus on system logic rather than detailed time advancements. It is widely adopted in simulation software for its visual and structured nature, supporting both stochastic and deterministic activity durations, and is effective for performance analysis in queueing-heavy environments.[5]

Three-Phase Approach

The three-phase approach is a structured methodology in discrete-event simulation that organizes the simulation cycle into three distinct phases to efficiently manage event processing, particularly when multiple events occur at the same simulation time. This method classifies events into bound (B) events, which are scheduled to occur at specific times, and unbound or conditional (C) events, which depend on the current system state and do not advance the clock. By handling all events at the current time before advancing, it minimizes redundant scans of the event list compared to pure event-scheduling methods.[21] Developed by Keith Douglas Tocher in the late 1950s as part of his work on the General Simulation Program (GSP), the approach was formalized in his 1963 book The Art of Simulation, marking it as one of the earliest systematic frameworks for discrete-event simulation programming. Tocher's innovation addressed the challenges of modeling complex industrial systems, such as those involving simultaneous activities, and influenced the design of simulation languages like GPSS (General Purpose Simulation System), introduced by Geoffrey Gordon in 1961, which adopted a similar phased structure for transaction-based modeling. The method gained prominence in the 1970s for its robustness in handling reactivations and state-dependent actions without excessive programmer intervention.[22][23] In the first phase, known as the test or α phase, the simulation scans the event list to identify the next scheduled time and advances the clock to that point, collecting all bound events due at the current time into a temporary "due now" list while leaving the clock unchanged for subsequent phases. This ensures precise time advancement only when necessary, referencing the simulation clock mechanism for synchronization. The second phase, or bound or β phase, executes all collected bound events, such as arrivals or activity completions, which update the system state and may schedule future events or trigger conditional checks; these events are time-bound and mandatory upon clock arrival. Finally, the unbound or γ phase scans for and executes any conditional events that can occur at zero time advance, such as state-dependent actions like resource allocations or immediate responses, repeating the scan until no further activations are possible at the current time. Examples include processing a queue service start immediately after an arrival if resources are available.[23][24][21] The simulation cycle repeats these three phases until termination conditions are met, advancing the clock only after the bound phase if additional future events exist, thereby ensuring comprehensive handling of all simultaneous events before progression. This repetition promotes efficiency by grouping executions at each time point. Compared to the event-scheduling approach, which processes events sequentially by advancing to and executing one at a time—potentially requiring multiple list scans for co-timed events—the three-phase method reduces overall scanning overhead through its batched processing, though it introduces minor phase management costs. It serves as an extension of event scheduling tailored for systems with frequent simultaneous or state-triggered activities.[23][21]

Applications

Manufacturing and Process Optimization

Discrete-event simulation (DES) has been instrumental in manufacturing since its early industrial applications in the late 1950s, when K.D. Tocher developed the first general-purpose DES package, the General Simulation Program, to model congestion and production flows in steelworks at United Steel Companies.[25] This pioneering work enabled the analysis of complex factory operations, setting the stage for DES as a tool to evaluate scheduling and resource allocation in industrial settings. Today, DES is widely used to simulate assembly lines and production processes, diagnosing operational issues such as machine downtime, which can cause cascading delays, and inventory buildup, which ties up capital and space.[26] For instance, in automotive and electronics manufacturing, DES models replicate real-time flows to pinpoint inefficiencies without halting actual production.[27] In these simulations, manufacturing entities—such as parts, products, or work-in-progress items—are tracked as they move through the system, while events represent discrete occurrences like machine startups, processing completions, breakdowns, or material arrivals.[28] This entity-event framework allows for detailed modeling of stochastic elements, including variable processing times and failure rates. A key technique is what-if analysis, where alternative scenarios are tested, such as reconfiguring factory layouts or adjusting machine sequences, to predict outcomes before implementation.[29] For just-in-time (JIT) production, DES optimizes schedules by simulating supplier delivery timings and buffer sizes, ensuring minimal inventory while maintaining flow.[30] The primary benefits of DES in manufacturing lie in its ability to quantify the effects of variability—such as supplier delays or equipment unreliability—on overall throughput and system performance, enabling data-driven decisions to enhance efficiency.[31] By identifying bottlenecks, DES supports targeted interventions that reduce waste and improve responsiveness. For example, in a Boeing composite wing assembly cell, DES modeling revealed that the bagging process accounted for 28% of cycle time with high variability; subsequent reconfiguration tested via simulation achieved a 46% reduction in that process's cycle time, boosting overall production capacity toward ramp-up targets.[31] Such applications demonstrate DES's role in achieving measurable gains, like increased output and lower operational costs, without the risks of physical trials.[32]

Healthcare Systems

Discrete-event simulation (DES) has been widely applied in healthcare to model complex patient flows, optimize resource allocation, and enhance operational efficiency in settings such as hospitals and clinics. By representing patients as entities that progress through a series of events like arrivals, registrations, treatments, and discharges, DES enables the analysis of dynamic interactions between patients, staff, and resources under varying conditions. This approach is particularly valuable for addressing bottlenecks in service-oriented systems where human factors and ethical considerations, such as patient safety and equity, play central roles.[33] In emergency department (ED) simulations, DES models incorporate triage priorities to differentiate patient acuity levels, simulating queue management states where higher-priority cases preempt lower ones to reduce critical wait times. For instance, entities arrive via random patterns modeled with Poisson distributions, triggering events such as vital sign assessments or diagnostic tests, with resources like nurses and beds allocated based on availability. A study of an ED in Taiwan used DES to evaluate bed allocation strategies, demonstrating that dynamic reassignment could decrease average patient length of stay by up to 20% and improve throughput without additional infrastructure. Similarly, in operating room (OR) scheduling, DES treats surgical cases as entities with attributes like procedure duration and surgeon availability, scheduling events to minimize delays from sequential dependencies or cancellations. Research evaluating distributed OR scheduling via DES found that reallocating cases across rooms increased utilization by 26% compared to the status quo, supporting better staff rostering and equipment sharing, though with a slight increase in overtime.[34][35] DES outcomes in healthcare often inform decisions on bed allocation and staffing, yielding measurable improvements in capacity and patient satisfaction. For example, a DES model for an outpatient clinic optimized bed and staff resources, achieving an increase in daily patient capacity through refined scheduling rules that balanced elective and urgent demands. These simulations prioritize conceptual insights, such as sensitivity to variability in arrival rates or treatment times, over exhaustive metrics, helping administrators test scenarios like peak-hour surges without real-world risks. Post-2020, DES has integrated with pandemic modeling to assess surge capacity, simulating COVID-19 patient inflows to predict ICU bed needs and ventilator allocation. A 2021 study applied DES to balance hospital resources during the COVID-19 crisis, showing that a ring-fencing strategy prioritizing life-saving surgeries could improve overall hospital performance by up to 20% compared to reactive approaches.[36]

Telecommunications and Networks

Discrete-event simulation (DES) plays a pivotal role in telecommunications and networks by modeling the dynamic behavior of communication systems, where events such as packet arrivals and transmissions occur at irregular intervals. In packet-switched networks, DES enables the analysis of congestion by simulating shared links among multiple users, capturing delays in packet acknowledgments proportional to traffic loads. This approach facilitates the evaluation of end-to-end congestion control mechanisms, often implemented using supervisory control theory to optimize link utilization.[37] A key use case involves assessing routing algorithms under varying loads, particularly in dynamic environments like flying ad-hoc networks (FANETs), where DES simulators test protocol performance by scheduling events for node movements and path selections. These simulations reveal how algorithms adapt to topology changes, ensuring reliable data routing in high-mobility scenarios. Similarly, DES supports the evaluation of Internet routing protocols, such as OSPF and BGP, by modeling event-driven updates and convergence times under stress conditions.[38][39] In modeling, packets serve as primary entities, with events representing arrivals at queues, transmissions across links, and drops due to buffer overflows. Protocol stacks are layered within the simulation, incorporating behaviors like TCP retransmissions triggered by timeout or duplicate acknowledgment events, allowing for accurate replication of real-world interactions. For instance, integrating production-quality TCP/IP stacks, such as FreeBSD, into DES frameworks enables high-fidelity simulation of congestion avoidance and flow control mechanisms.[40][41] Key insights from DES applications include identifying bottlenecks in bandwidth allocation, where simulations highlight critical links that limit overall throughput under bursty traffic. In quality-of-service (QoS) scenarios, priority queuing models prioritize high-importance packets, demonstrating improvements in latency reduction—up to 30% in high-load conditions—while maintaining fairness for lower-priority flows. These findings guide network design decisions, such as buffer sizing and scheduling policies.[42][43] Specialized tools like NS-3, a discrete-event network simulator targeted at Internet systems, are widely used for protocol testing in telecommunications, supporting modules for Wi-Fi, LTE, and TCP/IP to simulate realistic traffic patterns. Similarly, OMNeT++ facilitates extensible models for network layers, often integrating real protocol implementations for validation. These platforms emphasize event scheduling for efficiency in large-scale simulations.[40][44]

Financial and Investment Analysis

Discrete-event simulation (DES) is widely applied in financial and investment analysis to evaluate risks associated with market trades and portfolio management by modeling sequences of discrete events such as order executions, price fluctuations, and transaction settlements. For instance, simulators like StockYard employ DES to replicate stock market exchanges, where trades are represented as events in an order book that match buy and sell orders asynchronously, allowing for the assessment of market impact from large trades and the testing of trading strategies under stochastic conditions. This approach enables investors to quantify potential losses from adverse market movements, such as slippage or volatility spikes, by running multiple scenarios that incorporate noise traders and strategy-based agents to mimic real-world variability.[45] In capital budgeting, DES facilitates the analysis of project viability under uncertainty by simulating event-driven cash flows, including milestones like equipment installations or production starts, which can be delayed or disrupted by random variables. Events such as economic shocks or supplier defaults are modeled to integrate with Monte Carlo methods for generating price paths, providing a hybrid framework that captures both discrete occurrences and continuous stochastic processes in investment returns. This modeling supports net present value (NPV) calculations by discounting event-timed inflows and outflows, revealing how flexibility options—such as project abandonment or expansion—affect overall profitability; for example, simulations have shown that incorporating real options can increase NPV by 20-30% in research and development projects compared to static discounted cash flow models.[46][47] The value of DES in finance lies in its ability to provide decision support through stress-testing, where extreme events like correlated defaults are simulated to evaluate portfolio resilience and inform capital allocation. Financial risk metrics, such as Value at Risk (VaR), are generalized to DES outputs by treating simulation trajectories as asset return paths, allowing for the computation of tail risks in event sequences rather than continuous time series. Post-2008 financial crisis, DES adoption surged for systemic risk modeling in banking, with network-based simulations of interbank defaults and shocks demonstrating that targeted capital injections can reduce contagion probabilities by up to 40% under high shock rates (>1.5 standard deviations), outperforming traditional metrics like capital adequacy ratios.[48][49]

Comparison and Extensions

Versus Continuous Simulation

Discrete-event simulation (DES) models systems where changes in state occur at discrete points in time, driven by specific events such as arrivals or departures in a queue, whereas continuous simulation addresses systems with variables that evolve smoothly over time, often governed by differential equations representing phenomena like fluid flows or population growth.[50][51] This distinction arises because DES focuses on instantaneous state transitions triggered by events, while continuous simulation captures gradual, ongoing dynamics without discrete jumps.[50] In terms of methods, DES advances the simulation clock directly to the next event time using an ordered event list, allowing efficient skipping of inactive periods, as exemplified in queueing models where time only progresses when an entity joins or leaves.[51] Conversely, continuous simulation employs numerical integration techniques, such as Runge-Kutta methods with fixed or variable time steps, to approximate the solution of ordinary differential equations over continuous intervals, ensuring accurate tracking of variable rates like chemical reaction kinetics.[52] These approaches differ fundamentally in time handling: DES is event-driven and asynchronous, while continuous methods are time-stepped and synchronous.[50] Selection criteria for DES versus continuous simulation depend on the underlying system dynamics; DES is appropriate for sparse-event systems, such as manufacturing lines where activity is punctuated by discrete operations like machine setups, enabling detailed stochastic analysis.[51] Continuous simulation suits dense, interconnected processes, like chemical reactions where variables change continuously due to feedback loops, providing insights into long-term behavioral patterns.[50] For systems combining both, hybrid approaches integrate DES for discrete components with continuous modeling for fluid-like elements, as in supply chains with both inventory flows and order events.[51] Trade-offs highlight DES's computational efficiency in low-activity scenarios, where event skipping reduces processing time compared to stepping through every interval in continuous methods, but it may underrepresent smooth phenomena, leading to approximations in hybrid contexts.[50] Continuous simulation offers higher fidelity for gradual changes yet incurs higher costs for sparse systems due to unnecessary computations during idle periods, with differences in results diminishing as system scale increases—for instance, steady-state estimates converging within 1% in larger models.[50]

Advantages and Limitations

Discrete-event simulation (DES) offers significant efficiency advantages in modeling systems where changes occur infrequently or at discrete points, as it advances simulation time directly to the next event rather than iterating through fixed time increments. This approach avoids unnecessary computations during periods of inactivity, making it particularly suitable for event-sparse environments such as queueing networks or service systems.[53][5] DES naturally accommodates stochastic elements and variability by incorporating probability distributions for event timings and outcomes, enabling realistic representation of uncertainty without assuming deterministic behavior.[5] Furthermore, its scalability supports the analysis of complex queueing structures and resource constraints, where entities interact dynamically, providing insights into bottlenecks and performance under varying loads.[53] Despite these strengths, DES has notable limitations, particularly in its inability to accurately capture continuous processes where system states evolve smoothly between events, such as fluid flows or chemical reactions, as it overlooks intra-event dynamics and assumes instantaneous changes.[50] In densely event-populated models, the future event list can grow excessively large, leading to computational overhead in list management and potential inefficiencies in simulation execution.[5] Additionally, visualizing and interpreting continuous aspects within discrete frameworks remains challenging, often requiring approximations that may introduce errors in systems with blended dynamics.[54] To address these constraints, hybrid approaches combining DES with continuous simulation methods have been developed, allowing discrete events to trigger or interface with continuous models for more comprehensive representations of mixed systems.[55] Approximation techniques, such as embedding minor continuous elements via embedded differential equations or simplified rate-based updates, can also mitigate inaccuracies without fully transitioning to continuous paradigms.[56] Overall, DES excels in operational research for discrete, stochastic systems like manufacturing queues or service operations but is less ideal for physics-oriented simulations dominated by continuous phenomena.[53][5]

References

  1. [PDF] Discrete-Event Simulation - Computer Science
  2. [PDF] Introduction to Discrete-Event Simulation and the SimPy Language
  3. What is discrete event simulation, and why use it? - NCBI
  4. [PDF] Discrete-Event System Simulation FouRTH EDITION
  5. [PDF] Discrete-Event Simulation: A First Course - SciSpace
  6. A history of discrete event simulation programming languages
  7. The development of the General Purpose Simulation System (GPSS)
  8. 2.4 Simulating a Queueing System By Hand
  9. [PDF] Simulation Modeling and Analysis, FIFTH EDITION
  10. [PDF] CHAPTER 5 NEXT-EVENT SIMULATION - DMI Unict
  11. [PDF] A Fast O(1) Priority Queue Implementation for the Simulation Event ...
  12. [PDF] Distributed Discrete-Event Simulation - UT Computer Science
  13. Random-Number Generation
  14. Random number generators: good ones are hard to find
  15. [PDF] 1 Inverse Transform Method
  16. [PDF] 1 Acceptance-Rejection Method
  17. [PDF] RANDOM NUMBER GENERATION WITH MULTIPLE STREAMS ...
  18. The Art Of Simulation : Tocher, K.D - Internet Archive
  19. [PDF] Modeling and Simulation Worldviews
  20. [PDF] General Principles of Discrete-Event Simulation Systems
  21. [PDF] A BRIEF HISTORY OF SIMULATION
  22. [PDF] Discrete Event Simulation Peer-Olaf Siebers
  23. [PDF] An overview of discrete event simulation methodologies and ...
  24. A history of simulation development in the united kingdom
  25. (PDF) A review of the application of discrete event simulation in ...
  26. Optimizing Automotive Manufacturing Processes with Discrete-Event ...
  27. Discrete Event Simulation - an overview | ScienceDirect Topics
  28. https://www.autodesk.com/blogs/design-and-manufacturing/how-discrete-event-simulation-helps-manufacturers-make-better-decisions/
  29. Discrete Event Simulation Software (DES) - Simio
  30. [PDF] Using discrete-event simulation to increase system capacity
  31. [PDF] Optimizing Production Line Layout in a Manufacturing Company ...
  32. [PDF] Application of Discrete-Event Simulation in Health Care: a Review
  33. Optimizing Emergency Department Patient Flow Through Bed ...
  34. https://www.tandfonline.com/doi/full/10.1080/01605682.2025.2557921
  35. Balancing scarce hospital resources during the COVID-19 pandemic ...
  36. A discrete-event systems model for congestion control - ResearchGate
  37. A FANET Simulator Designed and Implemented to Study Routing Algorithms
  38. Discrete event simulation-based performance evaluation of Internet ...
  39. ns-3 | a discrete-event network simulator for internet systems
  40. Integration of the freebsd TCP/IP-stack into the discrete event simulator OMNET++
  41. Modeling and Performance Analysis of Weighted Priority Queueing ...
  42. Performance Evaluation of a QoS-Aware Mechanism for Polling ...
  43. https://omnetpp.org/
  44. [PDF] StockYard: A Discrete Event-Based Stock Market Exchange Simulator
  45. Financial decision-making: using information generated by a ...
  46. Simulation and Monte Carlo: With Applications in Finance and MCMC
  47. [PDF] Transfer-and-Generalisation-of-Financial-Risk-Metrics-to-Discrete ...
  48. [PDF] NETWORK-BASED MODELING AND ANALYSIS OF SYSTEMIC ...
  49. [PDF] Discrete vs. Continuous Simulation: When Does It Matter?
  50. [PDF] A conceptual comparison between discrete and continuous ...
  51. [PDF] Numerical Methods of Simulating System Dynamics - RPI ECSE
  52. [PDF] Modeling using Discrete Event Simulation - ISPOR
  53. Advantages and disadvantages of discrete-event simulation for ...
  54. Hybrid simulation of continuous-discrete systems - ScienceDirect.com
  55. Discrete Event Simulation of Hybrid Systems
User Avatar
No comments yet.