Setting a Control Horizon

[cmhpwns]

In designing, configuring, and simulating MPCs, I am used to setting a control horizon, often distinct from the prediction horizon, for use at every sampling instant of the controller. I saw in the documentation that the global option CTRL_HOR of a gekko model can be read but perhaps not written (if I try to set it, then run the MPC, then read the current CTRL_HOR, the CTRL_HOR has reset to the default value of points in the supplied time array). In the documentation it is written:

"When CSV_READ is on and the horizon time points are specified from the data file, the CTRL_HOR and PRED_HOR are set equal to the number of time steps present in the data file."

I do not believe that I want to turn CSV_READ off. Is there a way to set the control horizon? I was surprised to see this parameter not readily adjustable, as I had thought others commonly use it for tuning MPCs.

If it helps, I have mainly been looking at the gas pedal example on the wiki: http://apmonitor.com/wiki/index.php/Main/Control

[APMonitor]

You are correct that m.options.CSV_READ=0 isn't compatible with gekko because the CSV file is how gekko communicates values to the MPC application. I recommend that you have a non-uniform time horizon such as m.time = [0,1,2,3,4,5,6,10,14,20] where the [0,1,2,3,4,5,6] is like you control horizon and [10,14,20] is finishes off the prediction horizon. The purpose of the prediction horizon is to (1) reduce the number of degrees of freedom (MV moves) to be isolated near the beginning, (2) get a steady-state value of the MVs, and (3) make sure the controller can reach the desired target. The non-uniform time horizon should accomplish most of those objectives. If you really need it for you application then I recommend that you make this a feature request so that the development can be prioritized.

[cmhpwns]

Sorry, I am still new to GEKKO / APmonitor as a whole.

The non uniform time horizon seems like a possible workaround somewhat akin to input blocking; the solver still calculates optimal MV moves for the end of the non uniform time horizon just as it does for uniform ones (ctrl horizon m still equals pred horizon p). I was able to eliminate the MV cycling I was observing by using relatively high MV change weighting in the cost function and using max MV change limits. This behavior seemed a bit odd to me so I will try cross checking these results with other MPC platforms as well.

Before closing I am still unclear on why the horizons were implemented this way. Does APMonitor believe there are advantages for setting m = p in most cases or was it simply a feature that got pushed out due to more pressing issues? I am not trying to say one way is right or wrong, but was wondering if there is something I am missing here

[APMonitor]

One of the unique things about Gekko MPC is that is includes both MV and CV tuning. Other MPC platforms typically either use a reference trajectory (CV tuning) or move suppression (MV tuning). There is more information on MV / CV tuning here: https://apmonitor.com/do/index.php/Main/ControllerTuning

Another parameter that you could try is MV_STEP_HOR that does MV blocking such as changing only 2 or 3 cycles of the MV.

You are correct that CTRL_HOR, PRED_HOR, CTRL_TIME, PRED_TIME, and other parameters are not fully supported in Gekko. I could add back in the CTRL_HOR concept, if needed. Specifying m.time to be whatever is needed makes PRED_HOR, CTRL_TIME, and PRED_TIME obsolete.

[cmhpwns]

That's a great animation! I don't think I need to be able to adjust the control horizon, but clarifying in the m.time +/or options.CTRL_HOR sections in the documentation that the control horizon can not be updated manually or adjusted (when CSV_READ is on and m.time is specified) may save future users some time. Nonetheless thanks for your replies and for this awesome package

[loganbeal]

@APMonitor would it be possible to use connections to fix the last n points of the MV together, effectively removing their degrees of freedom? Would there be any concerns with bug #59?
@APMonitor I agree that the documentation for CTRL_HOR, PRED_HOR, CTRL_TIME, PRED_TIME could more clearly state the limitations. I think I left these options in because I conceived a scenario in which the csv file wasn't used (just options and meas). Did we eventually make the csv critical? Is that scenario no longer possible? If so, we should probably just remove those global options altogether.

[APMonitor]

I don't think the CSV is critical but it is an important way to initialize variables from Gekko. There is no problem with #59 endpoint derivatives because an MV is a subclass of parameters and Param doesn't have a derivative. The easiest way to integrate this features is to turn off the degrees of freedom for the MV based on CTRL_HOR. It has a default value of 1 so I was using CSV_READ to determine when we would either use the data from the CSV file or use the specifications from CTRL_HOR, PRED_HOR, CTRL_TIME, PRED_TIME. Maybe we just need a vector that has length m.time that has a True or False for the MV dof. It could be an option for MVs.