# GEKKO wraps the APMonitor solver suite in a Python modelling language

> GEKKO is a Python package for machine learning and optimization that specialises in time series and differential algebraic equation systems, building an object model of constants, parameters, variables, equations and objective functions, and handing the compiled model to APMonitor's solver suite. It can run locally or against a remote server, and it is MIT licensed.

**BYU-PRISM/GEKKO** — GEKKO Python for Machine Learning and Dynamic Optimization

- Repository: https://github.com/BYU-PRISM/GEKKO
- Website: https://apmonitor.com/gekko
- Stars: 710 · Forks: 120
- Language: Python
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/byu-prism-gekko

## What GEKKO is a layer over

GEKKO is a Python package for machine learning and optimization, specialising in time series and differential algebraic equations systems, and it provides a convenient interface to the APMonitor optimization suite.

The distinction between the two matters. GEKKO is the modelling language, the part you write your problem in. APMonitor is the executable that does the work, and it is coupled with large-scale solvers for linear, quadratic, nonlinear and mixed integer programming, so LP, QP, NLP, MILP and MINLP are all in scope.

The modes of operation are the same list from two places. The README says they include parameter regression, dynamic data reconciliation, real-time optimization, dynamic simulation and nonlinear predictive control, and the setup.py description adds machine learning, discrete or continuous state space models, simulation, estimation and control, and calls out the problem classes explicitly, from LP and QP through to MPCCs, mathematical programming with complementarity constraints.

The project is the work of BYU-PRISM, and the homepage in the repository metadata is apmonitor.com/gekko, with the documentation at gekko.readthedocs.io. The licence is MIT, and the releases are v1.3.3 from 2026-10-19, v1.3.2 and v1.3.1 both from 2025-12-31, with the last push on 2026-10-19.

## The object model you build your problem in

GEKKO is described as a high-level abstraction of mathematical optimization problems, and the model is built from a small set of object types.

Values in the model are defined by Constants, Parameters and Variables. The values are related to each other by Intermediates or Equations. Objective functions are defined to maximize or minimize certain values. Objects are built-in collections of values and relationships, and objects can build upon other objects with object-oriented relationships.

That is a small vocabulary, and the point of it is that a model becomes a graph of typed relationships rather than a pile of assignments. An Intermediate is a value computed from others without being a decision variable, an Equation is a constraint, a Parameter is a known quantity that may be updated, and a Variable is something the solver chooses.

The setup.py puts it slightly differently, describing models as consisting of equations and variables that create a symbolic representation of the problem for a single data point or single time instance, and then saying that solution modes create the full model over all data points or the time horizon. So the same model description serves a single-point solve and a time-series solve, and the mode decides which.

That separation is what makes the dynamic modes work. The model is written once, and simulation, estimation and optimisation are different ways of solving it.

## The nine modes and what separates them

The APMonitor executable has several modes of operation, adjustable with the imode parameter, and the README lists all nine.

They are steady-state simulation (SS), model parameter update (MPU), real-time optimization (RTO), dynamic simulation (SIM), moving horizon estimation (EST), nonlinear control or dynamic optimization (CTL), sequential dynamic simulation (SQS), sequential dynamic estimation (SQE) and sequential dynamic optimization (SQO).

The grouping is described in the README and is more informative than the list. Modes 1 to 3 are steady state modes with all derivatives set equal to zero. Modes 4 to 6 are dynamic modes where the differential equations define how the variables change with time. Modes 7 to 9 are the same as 4 to 6 except the solution is performed with a sequential rather than a simultaneous approach. And each mode for simulation, estimation and optimisation has a steady state and a dynamic option.

So there are really three axes. Steady state against dynamic. Simulation, estimation or optimisation. And simultaneous against sequential for the dynamic cases. The sequential modes matter because a dynamic optimisation solved all at once over a long horizon is a much larger and much more fragile problem than one solved step by step, and the sequential approach trades optimality for tractability.

The core of all modes is the nonlinear model, and each mode interacts with that nonlinear model to receive or provide information. Everything else in the package is a way of driving that one model.

## How a solve actually happens

The solve path is worth understanding, because it explains the practical behaviour of the library.

The APMonitor executable on the back-end compiles a model to byte-code and performs model reduction based on analysis of the sparsity structure, which the README describes as the incidence of variables in equations or objective function, of the model. For differential and algebraic equation systems, orthogonal collocation on finite elements is used to transcribe the problem into a purely algebraic system of equations.

That transcription step is the technical heart of the package. A DAE system cannot be handed to an algebraic solver directly, so the continuous problem is discretised into a purely algebraic one, and the number of collocation points becomes the size of the resulting nonlinear program. It is also why the dynamic modes cost far more than the steady state ones.

What the solver receives is a sparse description: variables with default values and constraints, the objective function, the equations, evaluation of equation residuals, the sparsity structure, first derivatives and the gradient of the equations and of the objective function, and second derivatives including the Hessian of the Lagrangian.

Once the solution is complete, APMonitor writes the results in results.csv, which is loaded back into the Python variables by GEKKO. So the Python side is a client: it builds a model, ships it, and reads the answer back from a file.

The failure path is documented too. When the system of equations does not converge, APMonitor produces a convergence report in infeasibilities.txt, and there are other levels of debugging that help expose the steps APMonitor is taking to analyze or solve the problem. Setting APM.diaglevel to higher levels, from 0 to 10, gives more output, and setting APM.coldstart to 2 decomposes the problem into irreducible sets of variables and equations to identify infeasible equations or properly initialize a model.

## Installing it, and the local versus remote decision

Installation is a pip install:

```sh
pip install gekko
```

And an upgrade from the command line uses the upgrade flag:

```sh
pip install --upgrade gekko
```

The most recent version is listed on PyPI, and the docs are at gekko.readthedocs.io.

Then there is the decision that actually affects your deployment, which is where the solve happens. GEKKO runs in remote mode, solved on a high performance server, or on a local CPU when the option remote=False, such as m=GEKKO(remote=False).

The pip package includes the executables for each platform: the Windows executable apm.exe, a Linux executable apm, a MacOS executable apm_mac, and a Linux ARM processor executable such as for a Raspberry Pi, apm_arm. With Linux under WSL on an x86 platform, the Windows executable is used, and Gekko can be used with remote server access, the default option, for all operating systems.

So the default is a hosted server at APMonitor, and the local path is opt-in per model. That is unusual for a scientific Python package, and it has a practical consequence: your model, and the data attached to it, leaves your machine unless you set remote=False.

The setup.py makes the same point about platform reach, describing data cleansing functions and standard tag actions for industrially hardened control and optimization on Windows, Linux, MacOS, ARM processors, or any other platform that runs Python, with options available for local, edge and cloud solutions.

## The examples, and what the repository holds

The examples directory is the fastest way to understand what the library is actually used for, and the names are more informative than the README.

There are the notebooks, with Optimization_Introduction.ipynb, gekko_18examples.ipynb, Global_Optimization.ipynb, benchmark_Bryson_Denham.ipynb and Gekko_GPR_Optimization.ipynb for Gaussian process regression, plus Energy_Dispatch.ipynb. There is an ANN_CSTR_control.py for a continuous stirred tank reactor under control, distillation.py for a distillation column, and a set of hw_ files covering the canonical problems: hw_pendulum.py, hw_reservoirs.py, hw_cruisecontrol.py, hw_flightcontrol.py, hw_skydive.py, hw_NMPC.py, hw_LMPC.py, hw_MHEandMPC.py, hw_estimator.py, hw_collocation.py, and hw_HIV.py with a hiv_data.csv alongside it.

The hw_ prefix means homework, and the collection covers the standard nonlinear control curriculum: estimation, moving horizon estimation, nonlinear model predictive control, linear model predictive control, collocation, and a handful of classic control problems.

The repository layout also shows the scope. There is a gekko/ directory for the package, an examples/ directory, an e2e/ directory for end to end tests, a docs/ directory, a gekko-matlab/ directory, a gekko-skill.zip, a setup.py and setup.cfg, a MANIFEST.in, a CITATION.cff, a CHANGELOG.md and a CODE_OF_CONDUCT.md.

The presence of gekko-matlab/ and the MATLAB interface mentioned in the README, alongside Python and a web browser, tells you the modelling language is meant to be portable across the three, which matters if a lab has mixed tooling. The CITATION.cff means the project is set up to be cited properly from a repository sidebar.

## Where GEKKO fits, and where it stops

The realistic comparison is with a general purpose machine learning stack and with a traditional modelling tool, and the difference is the domain.

Against a machine learning library, GEKKO is not in the same category, and the README's own framing says so. The machine learning here is regression and optimisation over DAE models: data regression, parameter estimation, moving horizon estimation, and the model fitting that a GP regression notebook demonstrates. It is the modelling and optimisation of physical or process systems, and a library like PyTorch or scikit-learn is not a substitute for it because the problem being solved is different.

Against a traditional process simulation package, the difference is that GEKKO is a scripting language over a solver rather than a graphical tool. You get the same model classes, expressed in Python, with the solver detail handled by APMonitor. The trade is that you lose the graphical environment and you gain the ability to script an optimisation loop, sweep parameters, and version the model in a repository.

The limits are visible in the design. The dynamic modes are expensive because orthogonal collocation transcribes the DAE system into a purely algebraic one, so the size of the problem scales with the horizon and the number of collocation points, and a long horizon is a large nonlinear program. The local mode depends on a platform binary being present and matching, which is why the Windows executable is used under WSL on x86, and why remote mode is the default. And the model itself has to be written as a symbolic graph of typed objects, which is a real constraint on how you structure a large model.

The debugging story is better than it could be, though. The convergence report in infeasibilities.txt, the diaglevel control from 0 to 10, and the coldstart decomposition into irreducible sets are the tools you reach for when a model does not solve, and they are documented in the README rather than left to discovery.

## Conclusion

GEKKO suits a chemical or process engineer who wants to express a dynamic model, an estimator and a controller in one scripting language rather than in a specialised modelling suite, since the same object model covers parameter regression, simulation, moving horizon estimation and nonlinear predictive control. It is the wrong tool if you need a deep learning framework, because the machine learning here is regression and optimisation on DAE models rather than neural network training, and it is the wrong tool if you cannot accept a compiled executable in the loop, because the pip package ships platform binaries and the default mode is a remote server. Before adopting it, run the examples directory, in particular the notebook and the hw_ files, and set remote=False to see whether the local solver path is viable for your data volume.

## FAQ

### How do I install GEKKO?

With pip install gekko, and pip install --upgrade gekko to upgrade. The pip package bundles the platform executables, including apm.exe for Windows, apm for Linux, apm_mac for MacOS and apm_arm for Linux ARM processors such as a Raspberry Pi, and the Windows executable is used with Linux under WSL on an x86 platform.

### How do I run GEKKO locally instead of on the remote server?

Set remote=False when creating the model, for example m=GEKKO(remote=False), and the problem is solved on a local CPU. The default is remote mode, where the problem is solved on a high performance server.

### What are the nine modes of operation in APMonitor?

Steady-state simulation (SS), model parameter update (MPU), real-time optimization (RTO), dynamic simulation (SIM), moving horizon estimation (EST), nonlinear control or dynamic optimization (CTL), sequential dynamic simulation (SQS), sequential dynamic estimation (SQE) and sequential dynamic optimization (SQO). Modes 1 to 3 are steady state with all derivatives set to zero, modes 4 to 6 are dynamic, and modes 7 to 9 are the same as 4 to 6 but solved sequentially rather than simultaneously.

### How does GEKKO solve a differential algebraic equation system?

The APMonitor executable compiles the model to byte-code and performs model reduction based on the sparsity structure. For differential and algebraic equation systems, orthogonal collocation on finite elements is used to transcribe the problem into a purely algebraic system of equations, which is then solved by the coupled LP, QP, NLP, MILP and MINLP solvers.

### How do I debug a GEKKO model that does not converge?

APMonitor writes a convergence report to infeasibilities.txt when the equations do not converge. Setting APM.diaglevel to a higher level from 0 to 10 produces more output about the steps being taken, and setting APM.coldstart to 2 decomposes the problem into irreducible sets of variables and equations to identify infeasible equations or initialize a model properly.

## Sources

- [BYU-PRISM/GEKKO on GitHub](https://github.com/BYU-PRISM/GEKKO)
- [License: MIT](https://github.com/BYU-PRISM/GEKKO/blob/master/LICENSE)
- [Project website](https://apmonitor.com/gekko)
- [README](https://github.com/BYU-PRISM/GEKKO/blob/master/README.md)
- [Releases](https://github.com/BYU-PRISM/GEKKO/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/byu-prism-gekko