DESDEO: An Open Framework for Interactive Multiobjective Optimization

Abstract

We introduce a framework for interactive multiobjective optimization methods called DESDEO released under an open source license. With the framework, we want to make interactive methods easily accessible to be applied in solving real-world problems. The framework follows an object-oriented software design paradigm, where functionalities have been divided to modular, self-contained components. The framework contains implementations of some interactive methods, but also components which can be utilized to implement more interactive methods and, thus, increase the applicability of the framework. To demonstrate how the framework can be used, we consider an example problem where the pollution of a river is controlled. To solve this problem with four objectives, we apply two interactive methods called NAUTILUS and NIMBUS and show how the method can be switched during the solution process.

Appendix

In what follows, we give source listings of the river pollution problem solved in Sect. 4.2. As mentioned earlier, we consider a river that is polluted by a city and a fishery. The aim of the DM is to improve the quality of water and to minimize the costs incurred. The problem has four objectives and two variables, three of the objectives to be maximized and the fourth one to be minimized.

To understand how the problem can be solved, we provide the source code listing in the examples directory of the DESDEO framework as a file named NarulaWeistroffer.py. Note that the framework is under an active development.

Listing 1 Problem initialization

The initialization of the River Pollution problem can be seen in Listing 1. As mentioned earlier, all concrete problems must be derived from some base class. As the problem is formulated with Python, we import the PythonProblem class from the problem module, from which a RiverPollution subclass is derived. In the RiverPollution class, we first provide a description of the problem (with the relevant reference as a documentation string). We then proceed with the problem formulation.

Problem dimensions, variables and other characteristics are defined in the __init__ method of the problem class. Of those, only the number of objective functions and the box constraints of the decision variables are required, other parameters are optional. For the river pollution problem, the number of objective (nobj) is four, and it does not have other constraints (nconst) besides box constraints. As the ideal and nadir objective vectors are known they can be provided, but if they are not known, the method calculates them if needed. Even though the DESDEO framework assumes that all objective functions are to be minimized, it is possible to provide a value for the parameter maximized in order the DESDEO framework to convert objective function values whenever communicating from and to the user interface. If this value is not set, such conversions cannot be made, and they must be handled by the user interface. The value True of the parameter indicates that the objective is to be maximized and with False, it is to be minimized. It is also possible to give names to objective functions as well as a name for the problem as shown in the listing.

Finally, the problem requires decision variables provided with the add_variable method of the class with an instance of the Variable class. The Variable class is initialized with three parameters, namely box constraints giving upper and lower bound value for the decision variables, starting point to be used when solving the problem and name of the variable. Of these, only the first, box constraints, is required and the others are optional. If the starting point is not given but the single objective optimization method used requires a starting point, the lower bounds of the variables are used as the starting point. It should be noted that when the DESDEO framework is extended to handle problems with discontinuous variables, the variable handling must be changed.

Listing 2 Problem initialization

In Listing 2, we show how objective functions are given by overloading the evaluate method of the PythonProblem class. As an input parameter, the evaluate method takes a population, which is a set of decision variable vectors each representing a new objective vector to be calculated. This means that when called, the evaluate method evaluates objective function values for each decision variable vector in the population. If objective function values of a single decision vector are to be evaluated, the population should have only this single decision variable vector. As a return value, the evaluate method gives the objective vector as a list of objective function values.

Listing 3 Solving the problem with NAUTILUS

As mentioned, the DESDEO framework does not include a graphical user interface for solving problems. It does include a text-based framework for building iterative solution processes called tui. In Listing 3, we give an example on how the framework can be used with the tui module to solve a problem via a text-based interface using the first variant of the NAUTILUS method family (which was the first method used in the interactive solution process reported in Sect. 4.2).

In the first three lines of the Listing 3, we import additional classes and modules needed. That is, the tui module containing the text-based user interface, the class NAUTILUSv1 corresponding to the method and finally SciPyDE as the single objective optimization method to be used when solving the scalarized subproblems.

On the last three lines, we first initialize the method class by providing it with an instance of a multiobjective optimization problem formulated earlier and with the single objective optimization method SciPyDE to be used. The call to tui.iter_nautilus function in the line 7 starts the interactive solution process asking the DM to specify the preference information and returning the final solution obtained. On the last line, we print out the obtained solution which are converted from the minimized values to maximized using method problem.to_ui.

Listing 4 Interactive solution process with the NIMBUS method

In Listing 4, we give more details on how an interactive solution process can be implemented using the NIMBUS method as an example. The basic idea is same for all interactive methods currently implemented in the framework. As with the NAUTILUS example, we first import new classes needed when using the NIMBUS method, namely the NIMBUS class itself, and the NIMBUSClassification class to store the preference information obtained from the DM. We use the same RiverPollution and SciPyDE classes to initialize the method used on line 4. In contrast to the NAUTILUS example, here we do not use the tui module to get the DM’s preferences and to show solutions. Instead, they are given directly to show how the interactive solutions process is constructed.

On line 6, we set the previously obtained NAUTILUS_solution as the current, selected solution. On lines 8–12 new preference information is given as a NIMBUS classification and initialized as the class1 object of NIMBUSClassification. The preference information is the same as the information given be the DM in Table 2. New solutions are generated on line 13 with the nextIteration method of the NIMBUS object and printed out in line 14. This can then be continued until the final solution is found.