22 November 2022

In this article we continue the Python *Production mix* series. Specifically, we build Model 9 using the Gekko library.

Gekko is a Python package for machine learning, optimization of mixed-integer, and differential algebraic equations.

Our objective is to compare a model built using Gekko with the same model built using Pyomo.

## Articles in this series

Articles in the Python *Production mix* series:

- Python optimization Rosetta Stone
- Production mix - Model 1, Pyomo concrete
- Production mix - Model 2, Pyomo separate data
- Production mix - Model 3, Pyomo external data
- Production mix - Model 4, Pyomo json file
- Production mix - Model 5, Pyomo using def
- Production mix - Model 6, Pyomo abstract
- Production mix - Model 7, PuLP
- Production mix - Model 8, OR-Tools
- Production mix - Model 9, Gekko
- Production mix - Model 10, CVXPY
- Production mix - Model 11, SciPy
- Production mix - Conclusions

## Download the model

The model is available on GitHub.

## Formulation for Model 9

For this model, we're using the same general formulation that we used for previous models in this series, as shown in Figure 1.

## Model 9 Python code

### Import dependencies

The first task is to import the libraries that are needed for our program. As shown in Figure 2, we import the Gekko library, which we've previously installed, along with some other libraries that we'll use.

### Data file

The data for Model 9 is shown in Figure 3. We're using the json format that we used in some previous models. We specify the apopt solver, which is built-in to Gekko and suitable for solving linear and mixed integer problems. Other built-in solvers include bpopt (best for systems biology applications) and ipopt (a non-linear solver generally best for problems with large numbers of degrees of freedom or when starting without a good initial guess).

### Get data

We import the data from the json file using the code shown in Figure 4. This code is the same as the code we used for previous json files, apart from the filename.

### Declarations

As shown in Figure 5, we create the model and assign various data to the `Model`

. We maintain a code style that is similar to our previous models in this series.

Note that the model declaration includes a `remote`

parameter. Gekko models can be solved either locally or on a remote server. For our model, specifying the remote server leads to successfully solving the model, but attempting to retrieve the dual values produces an error because our code expects to find the values in the local temporary folder. We haven't found a way to retrieve the dual values when using the remote server option.

### Define the model

The model definition, as shown in Figure 6, starts with defining the variables. We explicitly define the objective function variable, unlike most other optimization libraries. We then define the production variables using a dictionary. While this approach is not required by Gekko, it is convenient.

The constraint and objective function definitions are very similar to previous models. Note that we specify the optimization direction using `Model.Maximize`

on the objective function variable.

We've adopted a simple style in this example, though we could use the `def`

structure that we've used in some previous models. When developing more complex models, it can be useful to adopt a `def`

structure, to make the model more flexible and easier to understand.

### Solve model

As shown in Figure 7, we convert our string name for the solver into an engine number, as expected by Gekko. We also define some options, including for the level of output that the solver produces during the solve process. We want to display dual prices in the results, so we need to specify a diagnostic level sufficient to enable us to do that. The diagnostic level can be varied from 0 to 5.

### Process results

The code for processing the solver result, as shown in Figure 8, is similar to the code for previous models.

### Write output

The code for writing the output, as shown in Figure 9, is very similar to our previous models. The main difference is the syntax for extracting the slack and dual values from the solver output files in the temporary folder.

When we find an optimal solution, the output is shown in Figure 10. This output is similar to previous models, except for the model's name. Also note that the dual prices having the opposite sign compared with previous models.

Finally, unlike most other libraries, we need to clean up after the solve is complete, as shown in Figure 11. The clean up process removes the solver's temporary folder.

## Evaluation of this model

This model is very similar to our Pyomo models. Although the syntax of the two libraries is somewhat different, the general structure of the model definitions and solution process is familiar.

Despite the similarities, we tend to prefer Pyomo for solving linear programs, simply because Pyomo is focussed on optimization modelling, while Gekko is focussed more on other applications.

## Next steps

In subsequent articles we'll repeat the model implementation using our other selected libraries. Next on the list is CVXPY, which is a modelling language for convex optimization problems.

## Conclusion

In this article we built the *Production mix* model using the Gekko library. Compared with the Pyomo models, the code is quite similar. Gekko is a capable modelling library that is easy to use. However, it is focussed more on machine learning and related applications, rather than optimization. Since Gekko offers no significant advantage compared with Pyomo, we tend to prefer Pyomo over Gekko for this type of model.

In the next article, we'll build the *Production mix* model using CVXPY.

If you would like to know more about this model, or you want help with your own models, then please contact us.