Do-mpc

Major fixes

- Solved 215
- Hoping to solve 233

Fixed an issue with release 4.3.0 where sampling tools where not included on pypi.

Major changes

do-mpc sampling tools

With this release we are integrated a major new feature in do-mpc which was originally started at the [do-mpc developer conference 2021](https://pas.bci.tu-dortmund.de/professorship/news/details/review-do-mpc-developer-conference-13195/).
To learn more about the new feature we have prepared a [video tutorial](https://www.youtube.com/watch?v=3ELyErkYPhE).

Minor changes

- Fixed an issue with saving computation time in MHE/MPC in data object.
- New example: Kite systems

Major changes

Full customization of the MPC or MHE optimization problem is now possible.
Instead of using ``MPC.setup()`` to finalize the MPC optimization problem, an alternative two step process is now possible:
- ``MPC.prepare_nlp()``
- ``MPC.create_nlp()``

In between these two calls, users can add custom constraints and terms to the cost function using state, input etc. variables from different time-steps, collocation points or scenarios.
A typical example would be to constrain changes of inputs or two enforce a cyclic behavior over the course of the horizon.

The new feature is fully documented and we suggest to have a look at the API reference for the MPC or MHE object.

Backend

Model

Internal functions in ``do_mpc.model.Model`` class have now properly named inputs and outputs. These inputs/outputs were previously automatically named ``i0, i1, ...``. They are now name e.g. ``_x, _u, _z ...``.

Here is an example (from the backend):

python
self._rhs_fun = Function('rhs_fun',
[_x, _u, _z, _tvp, _p, _w], [self._rhs], variables
["_x", "_u", "_z", "_tvp", "_p", "_w"], ["_rhs"]) names

This may help for debugging because we now have that:
python
model = do_mpc.model.Model("continuous")
....
model.setup()
print(model._rhs_fun)

Returns

Function(rhs_fun:(_x[6],_u,_z[3],_tvp,_p[2],_w[0])->(_rhs[6]) SXFunction)

Major changes

MX support
This addresses 34.
The do-mpc model class can now be created with the ``symvar_type`` argument, defining whether the model is using CasADi ``SX`` or ``MX`` optimization variables.

python
model = do_mpc.model.Model('continuous', 'MX')


all classes (MPC, MHE, Simulator ...) created from a MX model will also use MX variables.
From a users-perspective the change has no significant influence on the experience.
It does, however, allow for significantly faster matrix vector operations, which is main motivation to use the ``MX`` support.

The new feature resulted in some major changes to the backend.
This is because CasADi does not allow (e.g.):
python
x = MX.sym('x')
struct_symMX([
entry('x', sym=x)
])

on which the model configuration heavily relied on.

Most importantly:
- The Model class attributes ``_x``, ``_u`` etc. are now dicts prior to calling ``Model.setup``.
- Calling ``model['x']`` still works prior to calling ``Model.setup`` but works differently internally
- a new method ``_convert2struct`` converts dicts (e.g. of all the states) to symbolic structures (used in ``Model.setup``). The only problem: These structs hold variables with the same name but which are different.
- a new method ``_substitute_struct_vars`` is introduced and substitutes the variables in the dicts in all expressions (e.g. ``_rhs`` with the new variables from the symbolic structs.
- the MHE also required some major internal changes. The problem is that we split the parameters (``_p``) for the MHE into estimated and set parameters. Splitting symbolic variables with the MX type is problematic.

Minor changes
- Solved 149 : Option to only have a single slack variable (for each soft-constraint) over the entire horizon

Bug fixes
- Resolves 89. Discrete-time model now inherits its properties to MHE/MPC etc.

Major changes

Adapted time-varying parameters for MPC object

Time-varying parameters (tvp) are now defined for ``k=0,...,N+1`` as opposed to ``k=0,...,N`` in the previous version.
The main consequence is that the ``mterm`` for ``mpc.set_objective`` can now include the ``tvp`` in its expression.
This is beneficial e.g. for set-point tracking.

Documentation

Time-varying parameters are also described in greater detail now in [this](https://www.do-mpc.com/en/latest/FAQ.html#time-varying-parameters) article.