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 cannot be controlled directly. Typically, technique implementations (and
Optimization
Process Composer 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.
Assigned feasibility codes are meaningful only for designs that have been evaluated
successfully. The following table describes the design feasibility codes:
Value |
Designation |
Meaning |
0 |
Simulation code failed (no results) |
This design is unusable. |
1 |
Infeasible (constraint violations) |
This design violates one or more constraints. This design is not
as good as the previous best design (which is necessarily also
infeasible), 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. |
3 |
Infeasible - better |
This design violates one or more constraints. This design is
better than the previous best design. |
7 |
Feasible |
This design satisfies all constraints. This design is not as good
as the previous best design. 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. |