Development and implementation
5.2 MOOSolver: The user-interface for TPS
The MOOSolver user-interface for TPS is a Dialog object which allows user interac-tion with the suite. Many elements that form part of this object have already been described in the previous section where they were referred to as dedicated TPS objects for MOOSolver. This section focuses mainly on the graphical user-interface (GUI) and its elements. The GUI is the principal medium through which the user provides infor-mation about the simulation model to the suite. It is also the principal medium through which the user receives results from the suite. Unlike some of the other elements of the user-interface defined earlier (e.g. the callback method and the temporary stores), which are principally used in the background (i.e. outside the user’s sight), the GUI and its features are for direct interaction between the user and the MOOSolver library.
The design of the GUI was inspired by that of the TPS built-in optimisation suite GUI, namely, the GAWizard. The MOOSolver GUI for TPS was subsequently named the MSWizard.
This section is divided into two parts; in the first part, the author describes the GUI features used to input information about the simulation model as well as those used to input user-selected parameters for the algorithms. In the second part, the GUI features used to present (to the user) output results obtained by the suite are described.
(a) Define tab. (b) Run tab.
(c) Optimisation Parameters tab.
Figure 5.3: MSWizard GUI principal tabs.
5.2.1 GUI input features
The MSWizard has three main tabs named Define, Run and Optimisation Parameters.
Screen-shots of the wizard can be seen in Figure5.3. The following paragraphs describe the functions of each tab.
In the first tab (Figure 5.3(a)), the user defines the simulation model parameters.
The tab has three sections called group boxes. In the group box Decision variables, the user specifies the number of decision variables (DVs) in the model as well as their
respective paths (i.e. location) within the simulation model (see Figure 5.4). In the same table where the DV paths are specified, the user also provides all DVs respective boundaries as well as the DVs respective nature (i.e. whether they are discrete or continuous); the DVs boundaries are the limits (or constraints) that create a feasible solution space for the problem, following the MOSO framework of Chapter2.
Figure 5.4: Decision variables definition table.
In the second group box, the user defines the objective functions (OFs) following a similar approach to that of the first group box (see Figure 5.5). In addition to the paths of each OF, the user also specifies their respective optimisation directions.
Figure 5.5: Objective functions definition table.
The last group box is for the number of observations that the user wants MOOSolver to use for each solution that will be evaluated (i.e. a “blindly” selected n∗ similar to that of Section3.2.1).
In the second tab (Figure5.3(b)), the user runs the algorithms once all the param-eters have been correctly inserted. The first group box contains the button for starting the MOO CEM while the second group box contains the button for starting theMMY procedure. Before running the algorithms however, the user must specify additional parameters in the third and final tab.
Figure 5.6: MMY Scenarios table.
In the final tab (Figure 5.3(c)), the user specifies the MOO CEM parameters as well as the MMY parameters. For the MOO CEM, the user must select the values for epsilon, the maximum number of evaluations, the number of outer loops as well as the population size. (Please refer to Section4.2.1for descriptions on these parameters pertaining to their respective roles within the metaheuristic.) For theMMY, the user must specify the scenarios/systems or solutions to be compared as well as the respective IZ values of the objective functions (entered in the OFs definition table (Figure5.5)).
As already mentioned, MOOSolver allows the user to select up to 10 scenarios (see Figure 5.6) for reasons discussed in Section 4.2.2.2. Note that the columns in Figure
5.6are to follow the order according to which the DVs were defined. In other words, if DV 1 was defined before DV 2 in the columns of the DVs definition table (Figure5.4), then the values for DV 1 in the scenarios table must be in the first column and those for DV 2 in the second column etc. Note also that theMMY procedure has a preselected probability of correct selection value (90%) as was specified in Section 4.2.2.
5.2.2 GUI output features
The results obtained by MOOSolver are presented to the user in tables. In this section, the author describes the table formats for both the MOO CEM and theMMY.
Table 5.1: MOO CEM output table format.
Decision variables Objectives x11 · · · x1n f11 · · · fm ... ... ... ... xN 1 · · · xN n fN 1 · · · fN n
The output presented to the user at the end of the MOO CEM run, is a table that contains information about the approximate Pareto set obtained by the metaheuristic.
The table has the format illustrated in Tale 5.1, where n is the number of decision variables in solution xi, i = 1, ..., N , N the total number of solutions in the approximate Pareto set and m the number of objective functions, which in this study is always 2.
As the table can be overwhelmingly large, a better way of presenting the approx-imate Pareto set to the user is by plotting a Pareto front that contains the results to all the solutions in the Pareto set. Examples of Pareto fronts obtained by MOOSolver can be observed in Chapters 6 and 7. All the points in a Pareto front are results to specific solutions in the Pareto set and are hence, sometimes, referred to as solutions themselves. Using Pareto fronts is also a way of exploiting the fact that the number of objectives MOOSolver can handle at present is 2. In effect, when the number of objectives grows past 2 and 3, it becomes difficult to generate insightful graphical or visual representations of the Pareto set; the user, in this case must settle for the use of tables.
The output presented to the user at the end of theMMY run, on the other hand, is a table that contains information about the scenarios or solutions compared to each other
by the procedure. The table format is illustrated in Table5.2, where n is the number of decision variables in system xi, i = 1, ..., M , M the total number of preselected systems fed to the procedure and m the number of objective functions, which is again always 2 in this study.
Table 5.2: MMY output table format.
Decision variables Objectives Variances Rank Runs Status ID x11 · · · x1n f11 · · · f1m S112 · · · S1m2 ρ1 R1 St1 ID1
... ... ... ... ... ... ... ... ... ...
xM 1 · · · xM n fM 1 · · · fM m SM 12 · · · SM m2 ρM RM StM IDM
Additionally, Sij2 is the variance information of objective function j of system xi, j = 1, ..., m; ρi is the Pareto rank of system xi indicating the total number of systems in the set that dominate system xi. An integer value greater than 0 in this column indicates that system xi is dominated by ρi systems in the set and is thus not a correct selection. Ri is the total number of observations that was run for system xi during the execution of the procedure while Sti is the status of system xi indicating whether the necessary number of observations were run for the system. Since the procedure has a limited simulation budget to be run for every system (for practical purposes), if the budget were exhausted before the procedure could guarantee the statistical soundness of the system (with respect to the parameters used by the procedure in Step 1 of Algorithm 9), the Status column would indicate it. When a value of 0 is displayed for system xi, this indicates that the procedure was able to run the necessary number of observations for the system. Any other value (typically 1 or 2, which have themselves specific meanings in the context of the procedure implementation) indicates that the system needed more observations than allowed (in order to guarantee statistical soundness).
Finally, IDi is the ID of system xi with respect to the order in which the system was initially fed to the procedure by the user (via the Scenarios table). Since the order in which the systems are given to the procedure changes during the execution of the procedure, using IDs to identify each system once the runs are complete is more convenient than doing so with the help of decision variables.
5.3 Chapter summary
In this chapter, the development and implementation of the multi-objective optimisa-tion suite were presented. In particular, the inter-process communicaoptimisa-tion procedures used to integrate the suite with TPS were fully described. Moreover, the user-interface for TPS and its features were also described in great detail. In the next chapter, the product developed in this chapter is validated.
Chapter 6
Validation
In the previous chapter, the development and implementation of MOOSolver was pre-sented. MOOSolver, which is an optimisation suite for MOSO problems, was developed as a dynamic-link library and integrated with Tecnomatix Plant Simulation using, si-multaneously, C and COM inter-process communication technologies. It was also men-tioned in Chapter4 that two algorithms were selected for the suite, namely, the MOO CEM metaheuristic and theMMY procedure.
In this chapter, the suite is validated by using known MOO test problems as well as a variant of the buffer allocation problem discussed in Chapter 3. The MOO test problem will help validate the implementation of the MOO CEM and the BAP, that of theMMY procedure. Valid results also mean, automatically, that the IPC procedures used to integrate MOOSolver with TPS, namely C and COM, were both successful.