Understanding Run Grading

The following colors/shading styles are used with problem formulations:

• Light red (darker red in any graphs) represents an infeasible design point. For any infeasible run, the History tab will also use bold text to indicate the actual values that do not satisfy the defined constraints for any parameter, allowing you to easily determine why the point is infeasible.

• Green represents the best design point (based on the calculated objective). This point is always a feasible point (i.e., no violated constraints).

• Yellow represents the best design point but a point that is infeasible. This color is used when there is at least one objective defined and either there are no feasible points found or the best feasible point (colored green) has a worse calculated objective and penalty. In short, this point might be a better design even though it is slightly infeasible.

• Blue represents a Pareto point. When multiple objectives are defined in the problem formulation, there is no single “best point” but instead a set of points (called the Pareto set) from which tradeoffs can be made. For any one of these points, no improvement can be made in one objective without giving something up in another. A green or yellow point is actually also a Pareto point, but it is the one with the best calculated weighted sum objective and penalty value among all of the Pareto points.

• Any parameter values that cause the violation in infeasible runs are highlighted in bold.

You can disable the color coding of the rows on the History tab using the button at the bottom of the tab. The formulation information is saved, so that you can turn it back on at any time using the same button. Disabling the color coding has no impact on the performance of the Runtime Gateway. This also disables the min/max bars in the history table cells.

The following items are known characteristics/limitations when using the Problem Formulation feature on the Runtime Gateway:

• When altering the problem formulation in the Runtime Gateway (to see the effects on grading the runs), the corresponding process component’s internal configuration is changed in the loaded model to remain in sync. If you execute this model again in the Runtime Gateway, it uses this new configuration. The process component is not impacted if you re-execute the model from the Design Gateway.

• There is no option in the Runtime Gateway that allows you to reset to the original formulation with which the model was initially run.

• Changing the formulation to see how it affects the grading of the runs is a good way to interactively find design alternatives from among all the runs from the loaded job. However, it is not as effective as executing the model again with the new formulation since the process components can use this information to intelligently find better designs.

• Changing Problem Formulation in Runtime Gateway will internally recalculate Design Feasibility, Objective Function, Penalty Function, and Objective and Penalty parameters. The runs will be graded on the basis of these recalculated values. However, the recalculated values of these parameters are not stored in the results database and the History tab will still continue to show the old values corresponding to the Problem Formulation with which the job was originally executed.