Simulation Optimization Methods - Part 1

Learning Objectives

• To be able to discuss the context for simulation optimization
• To be able to recognize and formulate standard simulation optimization problems
• To be able to explain how penalty functions are used
• To be able to construct a KSL problem definition including input variables and constraints
• To be able to evaluate a simulation model within an optimization context

General Form of the Optimization Problem

\[ \min_{x\in S} g(x) \] Where:

\[ g(x) = E[g(x, \xi_i)] \\ S = \{x: E[h(x, \xi_i)] \leq 0 \} \]

• \(g\) is an objective function
• \(x\) represents the decision variables
• constraints \(x \in S\).
• \(\xi_i\) represents the randomness associated with the \(i^{th}\) observation (sample) for the objective function
• \(g(\cdot)\) and \(h(\cdot)\) represents a performance measure, both, estimated from the simulation.
• the inputs, \(x\), are vector-valued and the responses \(h(\cdot)\) may also be vectors.

What does the KSL provide?

The KSL’s ksl.simopt package contains functionality to implement and use simulation optimization algorithms for KSL models. The package has the following sub-packages:

• ksl.simopt.problem This package has classes that facilitate the definition of optimization problem instances. The functionality includes specifying the objective function, the decision variables, and the constraints.
• ksl.simopt.evaluator This package has classes that provide a well-defined interaction protocol with a simulation model. In essence, a general contract for what constitutes the inputs and outputs from the model is defined. This allows responses to be translated to solutions for problem instances that can be used by algorithms.
• ksl.simopt.solvers This package provides the algorithms and general functionality for iterative optimization methods. The KSL denotes these simulation optimization algorithms as solvers.
• ksl.simopt.cache This package provides basic functionality to cache (in memory) executions of simulation models. Because the execution of a simulation model may be a long-running task and algorithms may visit design points multiple times during the search process, the caching of solutions may be useful. This package defines general interfaces for caching solutions and simulation runs.

Problem Definition Variables

• Let \(I\) represent the set of input variables
  • Let \(x_i\) represent the \(i^{th}\) input variable, and \(\vec{x}\) represent a member of \(I\).
• Let \(G(\vec{x})\) be a random variable representing the objective function response from the simulation at input variable settings \(\vec{x}\).
  • The value of the objective function, \(G(\vec{x})\), should be a response from the simulation model.
• Let \(L\) represent the set of deterministic linear constraints.
• Let \(F\) represent the set of deterministic functional constraints with members \(f_i(\vec{x})\).
• Let \(R\) represent the set of constraints based on simulation responses with \(R_{i}(\vec{x})\) representing a random response from the simulation model as a function of the input variables.
• Let \(l_i\) and \(u_i\) represent known bounds on input variable \(x_i\).

Problem Definition Formulation

An instance of the ProblemDefinition class represents the following mathematical program:

\[ \min g(\vec{x}) = E[G(\vec{x})] \\ \sum_{i=1}^{|I|}a_{ij}x_i \leq b_j \quad \textrm{for} \quad j=1,\dots,|L|\\ f_{i} (\vec{x}) \leq c_{i} \quad \textrm{for} \quad i=1,\dots,|F|\\ E[R_{i}(\vec{x})] \leq r_i \quad \textrm{for} \quad i=1,\dots,|R|\\ l_i \leq x_i \leq u_i \quad \textrm{for} \quad i=1,\dots,|I|\\ \]

• The problems represented by the ProblemDefinition class may contain deterministic linear and functional constraints and constraints that are based on observed responses.
  • We call the latter response constraints.
• The input variables must be specified to be limited within some finite bounds.

KSL Problem Definition

class ProblemDefinition constructor(
    problemName: String? = null,
    val modelIdentifier: String,
    val objFnResponseName: String,
    inputNames: List<String>,
    responseNames: List<String> = emptyList(),
    val optimizationType: OptimizationType = 
      OptimizationType.MINIMIZE,
      indifferenceZoneParameter: Double = 0.0,
      objFnGranularity: Double = 0.0
) : IdentityIfc by Identity(problemName) 

KSL Problem Definition Basic Functionality

• adding/defining/validating input variables
• adding/defining linear constraints
• adding/defining functional constraints
• adding/defining response constraints
• randomly generating feasible points in the input space
• converting arrays of variables to valid input variables
• checking for different feasibility conditions and computing constraint violations
• specifying a penalty function for translating a constrained problem to an unconstrained problem
• representing neighborhoods for the problem

Functions to Compute Constraint Violations

The ProblemDefinition class facilitates the computation of each type of violation, individually for each constraint and in total via the functions:

• linearConstraintViolations(inputs: Map<String, Double>): DoubleArray
• totalLinearConstrainViolations(inputs: Map<String, Double>): Double
• functionalConstraintViolations(inputs: Map<String, Double>): DoubleArray
• totalFunctionalConstraintViolations(inputs: Map<String, Double>): Double

Users can use these functions to define their own penalty function forms.

Defining Decision Variables

class InputDefinition @JvmOverloads constructor(
    val name: String,
    val lowerBound: Double,
    val upperBound: Double,
    granularity: Double = 0.0
) 

Defining Linear Constraints

data class LinearConstraint(
    val equation: Map<String, Double>,
    override var rhsValue: Double = 0.0,
    override val inequalityType: InequalityType
       = InequalityType.LESS_THAN
) : ConstraintIfc

Defining Functional Constraints

class FunctionalConstraint(
    validNames: List<String>,
    val lhsFunc: ConstraintFunctionIfc,
    override val rhsValue: Double = 0.0,
    override val inequalityType: InequalityType 
     = InequalityType.LESS_THAN
) : ConstraintIfc {

Defining Response Constraints

class ResponseConstraint(
    val responseName: String,
    val rhsValue: Double,
    val inequalityType: InequalityType 
      = InequalityType.LESS_THAN,
    val target: Double = 0.0,
    val tolerance: Double = 0.0
) {

Example (r, Q) Inventory Policy

An inventory manager is interested in understanding the cost and service trade-offs related to the inventory management of computer printers. Suppose customer demand occurs according to a Poisson process at a rate of 3.6 units per month and the lead time is 0.5 months. The manager has estimated that the holding cost for the item is approximately $0.25 per unit per month. In addition, when a back-order occurs, the estimate cost will be $1.75 per unit per month. Every time that an order is placed, it costs approximately $0.15 to prepare and process the order. The inventory manager wants to find the optimal setting for the reorder point and the reorder quantity with respect to the total ordering and holding cost while ensuring a fill rate of at least 0.95. Set up a KSL simulation optimization problem for this situation.

Make Sure Controls are Defined

The model needs to have controls defined for the decision variables.

    @set:KSLControl(
        controlType = ControlType.INTEGER,
        lowerBound = 0.0
    )
    var initialReorderPoint: Int
        get() = myInitialReorderPt
        set(value) {
            setInitialPolicyParameters(value, myInitialReorderQty)
        }

    @set:KSLControl(
        controlType = ControlType.INTEGER,
        lowerBound = 1.0
    )
    var initialReorderQty: Int
        get() = myInitialReorderQty
        set(value) {
            setInitialPolicyParameters(myInitialReorderPt, value)
        }

Naming Convention for Controls and Responses

The names of the two controls will be the strings:

• “Inventory:Item.initialReorderQty”
• “Inventory:Item.initialReorderPoint”

The fill rate and total ordering and holding cost responses have similar naming conventions resulting in these strings:

• “Inventory:Item:FillRate”
• “Inventory:Item:OrderingAndHoldingCost”

Setting up the model

• We need to know the model identifier.
• By default, this will be the assigned the name of the model, but in general it is user assignable.
• The basic code for building the reorder point, reorder quantity inventory model is as follows:

val reorderQty: Int = 2
val reorderPoint: Int = 1
val model = Model("RQInventoryModel")
val rqModel = RQInventorySystem(model, reorderPoint, reorderQty, "Inventory")
rqModel.initialOnHand = 0
rqModel.demandGenerator.initialTimeBtwEvents = ExponentialRV(1.0 / 3.6)
rqModel.leadTime.initialRandomSource = ConstantRV(0.5)
model.lengthOfReplication = 20000.0
model.lengthOfReplicationWarmUp = 10000.0
model.numberOfReplications = 40

• Thus, the model identifier will be the string “RQInventoryModel”.

KSL (r,Q) Problem Definition

val problemDefinition = ProblemDefinition(
    problemName = "InventoryProblem",
    modelIdentifier = "RQInventoryModel",
    objFnResponseName = "Inventory:Item:OrderingAndHoldingCost",
    inputNames = listOf("Inventory:Item.initialReorderQty", "Inventory:Item.initialReorderPoint"),
    responseNames = listOf("Inventory:Item:FillRate")
)
problemDefinition.inputVariable(
    name = "Inventory:Item.initialReorderQty",
    interval = Interval(1.0, 100.0),
    granularity = 1.0
)
problemDefinition.inputVariable(
    name = "Inventory:Item.initialReorderPoint",
    interval = Interval(1.0, 100.0),
    granularity = 1.0
)
problemDefinition.responseConstraint(
    name = "Inventory:Item:FillRate",
    rhsValue = 0.95,
    inequalityType = InequalityType.GREATER_THAN
)

Representing the Simulation Oracle

• The simulation oracle is a term used to represent the concept of the simulation model as a “black-box” that accepts inputs and returns outputs.
• To be able to define general problems and have them solved by general algorithms, a protocol needs to be established to represent the inputs, the model, and the outputs for generation, use, and consumption by optimization solvers.
• The purpose of the ksl.simopt.evaluator package is to provide classes and interfaces that establish this interaction protocol.

SimulationOracleIfc

Simulation Evaluator

Model Inputs

data class ModelInputs(
    val modelIdentifier: String,
    val numReplications: Int,
    val inputs: Map<String, Double> = emptyMap(),
    val responseNames: Set<String> = emptySet(),
    val requestTime: Instant = Clock.System.now()
)

Model Inputs and Equality

Model inputs have a very special representation for determining their equality. Two instances of the ModelInputs class are considered equal if:

1. the modelIdentifier properties are equal, and
2. the responseNames properties are equal (contain all the same response names), and
3. the inputs properties are equal (contain the same (key, value) pairs)

It is important to note that two instances will be considered equal even if their number of requested replications are different. This definition of equality facilitates the caching of results by model inputs.

Model Outputs

Representing Solutions

data class Solution(
    val inputMap: InputMap,
    val estimatedObjFnc: EstimatedResponse,
    val responseEstimates: List<EstimatedResponse>,
    val evaluationNumber: Int,
    val isValid: Boolean = true
) : Comparable<Solution>, FeasibilityIfc by inputMap, 
EstimatedResponseIfc by estimatedObjFnc

Solution Feasibility

Feasibility is established with respect to the problem instance. There are four types of feasibility modeled.

• Input range feasibility - If the input values are within the ranges defined for the input variable, then the solution is considered input range feasible.
• Linear constraint feasibility - If the input values satisfy all linear constraints, then the solution is considered feasible with respect to the linear constraints.
• Functional constraint feasibility - If the input values satisfy all functional constraints, then the solution is consider feasible with respect to the functional constraints.
• Input feasible - If the input values are input range feasible, linear constraint feasible, and functional constraint feasible, then the solution is considered input feasible.

Notice that feasibility ignores the issue of feasibility with respect to the response constraints.

Summary

The ksl.simopt.evaluator package permit requests for simulation evaluations. The inputs to the simulation model are contained within the request. The simulation model is executed at the specified inputs and the requested results returned. For simulation optimization algorithms, the input-output mapping is encapsulated within instances of the Solution class.

The Solution class contains information on the following:

• The inputs used to execute the simulation.
• The value of the objective function estimated via simulation, the penalized objective function value, and the constraint violations.
• The estimated responses involved in any response constraints.
• The ability to assess the feasibility of the solution with respect to the inputs and deterministic constraints.