About Optimization Feasibility

Optimization techniques classify the designs that they evaluate into feasible and infeasible designs. A design is feasible if it satisfies all the constraints placed upon the design space during execution of an optimization technique. A design is infeasible if it violates one or more of those constraints.

The concept of feasibility is used to distinguish:

  • Designs that are physically constructible from designs that are not

  • Designs that fit as parts within a larger assembly from designs that do not fit

  • Designs that satisfy minimal performance requirements from designs that do not

For optimization, the term “constraints” specifically means “output constraints,” which are defined as requirements placed upon the output parameters of a design space because output values are not directly controllable. Typically, technique implementations (and Isight implementations in particular) enforce input constraints—they evaluate only designs within the specified design space—so the notion of “violation” does not apply to them.

The Optimization component marks the feasibility of evaluated designs by setting the Feasibility parameter of the Optimization Results aggregate parameter for each evaluated design. This member is an integer-valued parameter. For each evaluated design, the feasibility code assigned to this member reflects both the feasibility of the design and the relationship between the feasibility of the design and that of previously evaluated designs. The code values are calculated as described in the following table.

Code

Designation

Explanation

0

  

This design is unusable.

1

Infeasible

This design violates one or more constraints. This design is not as good as the previous best design (which is necessarily also infeasible - see [*] below), but it is not necessarily the worst design.

2

Infeasible - Tie

This design violates one or more constraints. This design is as good as the previous best design (which is necessarily also infeasible - see [*] below).

3

Infeasible - Better

This design violates one or more constraints. This design is better than the previous best design (which is necessarily also infeasible - see [*] below).

7

Feasible

This design satisfies all constraints. This design is not as good as the previous best design in terms of the calculated ObjectiveAndPenalty (objective + penalty for constraint violation). There may be an infeasible design that could be considered better than this design if the constraint violation is small.

8

Feasible - Tie

This design satisfies all constraints. This design is as good as the previous best feasible design and is better than any infeasible design.

9

Feasible - Better

This design satisfies all constraints. This design is better than the previous best (feasible or infeasible) design.

[*] – A feasible design is always considered better than any infeasible design. As a result, feasibility codes 2 and 3 end up being used only until the first feasible design is evaluated.

Feasibility code values 4, 5, and 6 are not used. The code values used in Isight have been chosen to coincide with the feasibility code values used in the earlier product iSIGHT. In iSIGHT, code values 4, 5, and 6 are used only by a particular optimization technique that has not been implemented in Isight.

Assigned feasibility codes are meaningful only for designs that have been evaluated successfully. If execution of the Optimization component’s simulation process flow failed for some design, the value of the Feasibility member for that design is disregarded (most likely it will have the value 0, denoting an unusable design).

Warning: Different optimization components within a model may apply different constraints to the same underlying submodel. In that case you must be careful when interpreting feasibility codes among two or more optimizations.