Made popular by the Seinfeld television series, the Soup Man restaurant in New York City demands that customers know what kind of soup they want before arriving at the counter. Signs are prominently displayed, stating the rules in several languages:
FOR THE MOST EFFICIENT AND FASTEST SERVICEHave your money ready!
Move to the extreme left after ordering!
Failure to follow these rules may result in the harshest of penalties — no soup for you!
Like the Soup Man restaurant, the optimization process is not well suited to those who don’t have a clear set of goals in mind.
If we were to post a sign that stated the rules for preparing to do an optimization study, it might look like this:
THE GOALS OF THE STUDY MUST BE DEFINED.
Define the necessary constraints!
Select your design variables!
Then build the needed math models!
This initial step of defining goals, variables and math models seems straightforward, but it often requires serious thought and domain expertise. Lively debate among members of the design team is common during this process.
Often the biggest hurdle to completing this planning step is our eagerness to start building the first set of math models to test our latest brainstorm. Why bother arguing about specific goals and properly defining the design space when we already have a great solution in mind that just might work? Then, after several failed manual iterations, we usually return to the planning table, short on new ideas and even shorter on time. No soup for you!
Ideally, we shouldn’t begin building math models until we understand our goals and the parameters we will vary to meet those goals. Only then can we build suitable parametric models that fully capture the design intent and predict the system responses that correspond to our objectives and constraints.
Another common hurdle is deciding on the real goals. It is not usually possible to minimize or maximize everything in a system without violating the laws of physics. Some goals are bound to conflict with one another. You will often need to compromise by selecting certain goals as objectives while defining others as constraints. For example, instead of minimizing cost and maximizing performance, an optimization study might aim to find the lowest cost solution (the objective) that meets a minimum allowable level of performance (the constraint).
When you can easily define the required level of a system property or response, then it is natural to categorize this condition as a constraint. If you cannot easily determine the desired maximum or minimum value for multiple responses, you now have the option to perform a multi-objective optimization study that predicts the trade-offs among two or more objectives.
Instead of converging toward a single design based on a single objective, a multi-objective study yields a set of optimal designs that lie on a curve (for two objectives) or a surface (for three or more objectives), called a Pareto front. You can then select the design on the Pareto front that best meets your overall goals, with confidence that the most appropriate trade-offs have been considered for the current situation.
The additional information provided by a multi-objective optimization study can be extremely helpful in understanding your system and in making design decisions. But a multi-objective study requires additional computational resources, so it should only be used when the trade-offs are desired or when you really cannot decide ahead of time on a single objective.
Clearly this approach should never be used when visiting the Soup Man.
- Objectives are the properties or responses of your system that need to be minimized or maximized. For example, you may want to minimize cost or maximize performance.
- Constraints are the properties or responses of your system that must comply with specified limits. For example, the durability of the system may need to be at least as good as last year’s model. An even greater durability is allowed, but not required.
- Variables are the parameters in your system that can be changed in order to satisfy the objective(s) and constraints. For example, you may allow the material and gage thickness to change in four different parts, resulting in eight system design variables.
- Math Models are the predictive analysis models that are used to measure how good each design is. For example, for each set of design variable values you might use a finite element model to predict the thermal stresses of a structure, and a spreadsheet model to predict its cost. Developing the math models is not part of this step, but agreeing upon what types of models are needed is.