A MOLP is a linear program with more than one objective functions. The linear constraints are arranged in a matrix form with c columns and r rows. Columns correspond to variables x₁, x₂, . . . , x_c, which are subject to the restrictions

The lower bound L_i can be -∞ and the upper bound can be +∞.

For each row 1 ≤ j ≤ r the j-th constraint is

A feasible solution is a tuple x = <x₁, x₂, . . . , x_c> which satisfies all constraints.

There are m ≥ 1 objectives, which are given as

The m-dimensional objective vector y = <y₁, . . ., y_m> is achievable if there is a feasible solution x which yields exactly these objective values.

The solution of a MOLP is the list of all extremal objective vectors. For a minimizing (maximizing) MOLP the objective vector y is extremal if there is no other achievable objective vector y' which would be coordinatewise ≤ y (or ≥ when maximizing).

The task of MOLP solver is to find the collection of all extremal objective vectors. These extremal vectors are called vertices as they form the vertices of an (unbounded) convex m-dimensional polytope.

This MOLP solver finds the extremal vectors by iterations. In each step one more extremal vector is added to the final list. The time required for an iteration varies widely from a couple of microseconds to several days. After each iteration the solver checks if the process has been interrupted by a SIGUSR1 signal. If it has, it switches to a quick and dirty method which might find further extremal vectors (but not necessarily all of them).

The linear constraints must have a feasible solution. Moreover, in a minimizing MOLP all objectives must be bounded from below, and in a maximizing MOLP all objectives must be bounded from above.

The algorithm is described in details in the paper Inner approximation algorithm for solving linear multiobjective optimization problems, Optimization (2021), 70:7, 1487-1511, DOI: 10.1080/02331934.2020.1737692

The program is invoked as

inner [options] <vlp-file>

The only obligatory argument is the file name which contains the description of the problem in vlp format. Accepted options are

Fine tuning the algorithm and the underlying scalar LP solver, and specifying the amount and type of information saved is done by giving values of several keywords. Each keyword has a default value, which is overwritten by the values in the config file (if specified), and those values are overwritten by the --KEYWORD=value command line options. Change tolerances with great care.

When the program terminates, the exit status is zero when the problem has been solved successfully; otherwise it indicates the failure condition:

When the program receives a SIGUSR1 signal, it stops the main cycle of iterations, and switches to a "quick and dirty" method to generate additional extremal solutions. (Actually, the oracle is asked about all facets of the actual approximation; it returns an extremal solution on or beyond that facet.) The method might miss extremal solutions, so the result is not known (can not) be complete. A second SIGUSR1 signal aborts this post-processing.

When receiving a SIGUSR2 signal (since version 2.8), the program creates a snapshot file containing the vertices and facets of the actual approximation. Similarly to checkpoint files, the snapshot file can be used to resume the computation from that point.

The name of the snapshot file is created as follows. If a checkpoint stub is provided after the -oc option, then 000.dmp is appended to the stub. If no -oc option is provided but there is a -o output file, then the extension of that filename is replaced by dmp. If neither -oc nor -o option is present, then no snapshot is created. When receiving a second SIGUSR2 signal, the same filename is used: the previous content is silently overwritten.

Signals are checked only when an iteration step has been completed, that is a new vertex has been added to the approximation. (These are the points when the data is guaranteed to be consistent.) Depending on the complexity of the problem and the number of intermediate vertices and facets, the time between these points vary from milliseconds to several days.

The threaded version of inner can use all available cores on the computer to speed up the computation. Multiple cores can help in the combinatorial part, when the work is distributed approximately uniformly among them. The LP part (oracle calls) is inherently single-threaded and cannot be speed up this way. Thus LP intensive problems (large number of columns and rows and only a few objectives) will not gain too much from multiple threads. Specifying more cores than available comes with a significant performance penalty.

The program uses a patched version of glpk, the GNU Linear Program Kit. First, glpk should be compiled after the patch has been applied. Unpack the glpk source. In the glpk-X.Y directory execute the command

patch -p1 < ../src/patch-X.Y.txt

assuming you have unpacked glpk in the root of this repository. Still in the glpk-X.Y directory run 'configure' and 'make' as follows:

./configure
make CFLAGS='-O3 -DCSL'

You must define CSL as all patches to glpk are encapsulated in #ifdef CSL blocks.

Changing to the directory INNER/src, the following command compiles inner linking the patched glpk routines statically:

gcc -O3 -W -I ../glpk-X.Y/src -o inner *.c ../glpk-X.Y/src/.libs/libglpk.a -lm

The threaded version requires defining USETHREADS and adding the flag -pthread:

gcc -O3 -W -I ../glpk-X.Y/src -o innerth -DUSETHREADS -pthread *.c ../glpk-X.Y/src/.libs/libglpk.a -lm

The 'examples' directory contains vlp files describing different MOLPs. File names contain three numbers separated by dashes: the number of objectives, the number of rows, and the number of columns. Each file starts with some comment lines.

Solutions are in the 'solution' directory. The same file name with the extension .res contains the list of vertices and facets. .out files contain progress reports, statistics, and parameter settings.

Laszlo Csirmaz, csirmaz@ceu.edu