article

What is Optimization?

Optimization begins with a model. For optimization in general, this model can be any system that accepts a set of inputs and then produces outputs. Optimization is the search for a set of inputs that produces the best outputs for a given model.

Within FlexSim, it is possible to optimize a simulation model. The inputs can be thought of as configuration options: How many people should be hired? Where should the storage racks be placed? What kind of machines would work best? The outputs can be thought of as results: What was the utilization of the workers? How long did items spend in the model? What was the total cost per item? FlexSim provides easy-to-use tools that allow you to specify the inputs and outputs for your model. Once this is done, FlexSim can intelligently search through the possible configurations to find the best possible outputs; in other words, it can find an optimal configuration of your model.

Note: This document contains a lot of information. If you are new to optimization in FlexSim, a good learning strategy would be to read this document, then do the optimizer tutorial, then read this document again.

Configurations, Scenarios, and Solutions

In FlexSim, the Simulation Experiment Control tool allows users to define scenarios for a model. A scenario consists of one value for each experiment variable, which results in a configuration of a model. The optimizer also generates configurations for a model based on the same set of variables used by the experimenter. In order to distinguish this kind of configuration from a scenario, it is called a solution. Users generate scenarios, and the optimizer generates solutions. Both configure a model based on the variables defined in the Experiment Simulation Control.

General Algorithm

When the optimizer is running, it is searching for better and better configurations for the model. Here's a basic version of that search algorithm:

1. Generate a model configuration (a solution).
2. Set the current model to match that configuration.
3. Run the simulation. This is also called evaluating the solution.
4. Get the outputs from that run
5. Rank the solution.
6. Generate a new solution based on the results from all evaluated solutions.
7. Repeat from step 2.

The above algorithm repeats until the optimizer runs out of time, evaluates a maximum number of solutions, is stopped by the user, or until it evaluates all possible solutions of the model.

Defining an Optimization

Variables

Optimization variables are the options for your model. When the optimizer generates a solution for your model, it is simply setting each of the variables to a specific value. There are different kinds of variables based on the option that is being represented. There is no limit to the number of variables that an optimization can have.

To add a variable to an optimization, add a variable to an the Scenario Table on the Simulation Experiment Control. If that variable can be manipulated by the optimizer, it will be automatically added to the list of variables for the optimizer. If necessary, the name of the variable will be modified to match the optimizer's variable name requirements.

Type	Description	Examples
Continuous	These variables represent options with a range of possible values. Any value within that range is a valid option for a model (4.354, 6.0, -10.45, etc.).	Values that can be very finely tuned (such as positions, lengths, and times) are often represented as continuous variables.
Integer	These variables represent options with a range of possible values. Any integer value within that range is a valid option for a model (-3, 5, 7, 25, etc.).	Quantities of discrete objects (number of people, items, etc.) are often represented as integer variables.
Discrete	These variables represent options with a range of possible values and a step between possible values. Only values that are exactly n steps from the lower bound are valid.	Values with discrete steps (part sizes, paired items, etc.) are often represented as discrete variables.
Binary	These variables represent options that only have two possible values: 0 and 1.	Values that represent options like yes/no, on/off, present/not present, etc., are usually represented as binary variables.
Design	These variables represent options that have a range, but a higher value does not represent "more" or "further." Instead, it just represents a different option. The optimizer will not assume that increasing this kind of variable will have a predictable effect on the system.	Values that represent options like machine type, overall floor layout, or packing strategy are usually represented as design variables.
Permutation	These variables come in groups; a single permutation variable is pointless. Permutation variables can have a value from 1 to n, where n is the number of permutation variables in a specific group. However, each value is guaranteed to be distinct. If there are three permutation variables in a single group, they can have the values like 1, 2, 3 or 3, 1, 2; they cannot have values like 1, 1, 2 or 3, 1, 3.	These variables are usually used to represent an order. For example, a part route could be represented with a permutation variable. In one configuration, Station 1 could be first, Station 2 second, and Station 3 third. In another configuration, Station 3 could be first, Station 1 could be second, and Station 2 could be third.

Performance Measures

Performance measures are the results of a model run. They usually represent things such as cost, revenue, throughput, risk, average time in system, utilization, etc. There is no limit the the number of performance measures monitored by an optimization.

All performance measures added to the Performance Measures tab in the Simulation Experiment Control are automatically added to the optimizer. If necessary, the name of the performance measure will be modified to match the optimizer's variable name requirements.

Constraints

Constraints are a way of specifying additional conditions that a given model must maintain. Because of the nature of simulation, many constraints are naturally enforced by the model. Occasionally, however, it is necessary to enforce additional relationships.

Constraints are mathematical expressions that result in boolean values. They can be composed of variables, performance measures, literal values, and basic mathematical functions. Examples of valid constraints are shown below:

processorPositionX < 30

numberOfEmployees * 500 > 0.5 * totalRevenue

0 < numberOfEmployees + numberOfTrucks < 30

If a given configuration breaks one of these constraints, it is marked as infeasible. The optimizer will only mark a configuration as optimal if it is feasible.

A constraint can have a comma-separated list of values; for example:

processorPositionX < (30, 35, 40)

If a constraint like this exists, the optimizer will basically run the optimization routine for each value in the list, but report the results as one set.

Note: The graphical display for the optimizer may not display correctly if a constraint list exists and multiple objectives are searched. The optimizer will correctly perform the search, but a different utility (such as Excel) will need to be used to visualize the results.

Objectives

Objectives are functions used to determine whether one configuration is better or worse than another. They are very similar to constraints, except they return an actual value rather than a boolean result. Objectives also have a direction; they can be maximized or minimized. For example, an objective function called "cost" might be something like:

machineCount * 5000 + throughput * 50

If cost were minimized, the optimizer would look for solutions with the lowest cost. If cost were maximized, the optimizer would look for solutions with the highest cost. It is very important to set the correct direction for each objective.

Search Modes

The optimizer has three different search modes. A search mode is the way the optimizer will use the objective function while it runs. The search modes are as follows:

• Single - The optimizer will try to maximize or minimize a single objective. The best solution found in the time given will be returned.
• Weighted - The optimizer will try to maximize the cumulative value of all given objectives. Each objective is given a weight and a direction. If a particular objective is to be minimized, its value is multiplied by -1 before it is added to the cumulative objective. The best solution found in the time given will be returned.
• Pattern - The optimizer will search for solutions that optimize all given objectives. This search mode returns a set of optimal solutions. They are optimal in that for each one, improving any objective worsens the others. For example, a given optimization may maximize profit and minimize cost. For a solution to be optimal, no other solution can exist that increases profit without increasing cost. This is also called "Pareto Optimal."

There are more options for weighted searches, including an objective min, max, and goal. These are not well documented, even by OptQuest; use at your own discretion. Leaving blank or at zero in FlexSim will make sure they are ignored.

Other Optimization Options

Because the optimizer must run a simulation to evaluate each solution, there are many options about those simulations that can be set, such as:

• The model run time per solution evaluation
• The model warmup time per solution evaluation
• The number of replications per solution
• The kinds of data that should be saved per replication

There are also many options about the optimizer itself that can be set, such as:

• The wall time - the amount of real time the optimizer will spend searching for an optimal solution
• The maximum number of solutions to evaluate
• The use of experimenter scenarios as solutions.

Running an Optimization

Once the optimization has been properly defined, the hard part is done. You can click the Optimize button on the Optimizer Run tab of the Experiment Simulation Control. At this point, FlexSim will use the same multi-threaded capability found in the experimenter to evaluate multiple solutions simultaneously. This allows FlexSim to rapidly search through generated solutions, as well as provide meaningful feedback about the progress of the optimizer.

Interpreting the Results

When the optimizer is finished, one (or several) solutions will be marked as optimal solutions. Unless the optimizer evaluated all possible solutions (which is generally impossible), then the optimal solutions are simply the best solutions that the optimizer found. They are not guaranteed to be the absolute best solutions. They are only guaranteed to be better than all other solutions that were evaluated.

The true value of the optimizer, however, will be missed if you only look for those few optimal solutions. As the optimizer searches for optimal solutions, it creates a database of each solution and its effects on the model outputs. This database can be used (with the proper application of statistical techniques) to find previously unknown relationships between model variables, or to determine which constraints were most restrictive. Using this data appropriately can lead to new insight into the behavior of the model.

Under the Hood

FlexSim uses the OptQuest engine from OptTek Systems, Inc. OptQuest is a trusted, industry-standard optimization engine that uses the latest evolutionary algorithms to effectively search complicated design spaces. More information on optimization with this engine can be found in the OptQuest documentation here.