Question about time, control horizon, and prediction horizon

[Charitha Buddhika Heendeniya]

Dear Sir,

I have a question regarding the TCLab linear PC example (https://apmonitor.com/do/index.php/Main/TCLabF).

In this example, we have,

# Run time in minutes
run_time = 5.0

# Number of cycles
loops = int(60.0*run_time)
tm = np.zeros(loops)

# 30 second time horizon
m.time = np.linspace(0,30,31)

I would like to know how these different time scales are related. 

For example, as per the documentation, m.time determines the discretization intervals of each discrete variable. So if I understand correctly, the variable Q1 in this example should have 30 discrete values. 

But then we have a control horizon (= prediction horizon) of 300 seconds. It is not clear to me if variables are defined for only 30 discrete time steps; how can we define a control and prediction horizon to be longer than that? 

Could you please clarify?

Regards

Buddi

[Adnan Aboudi]

Hi Buddi,

Here's a bit of a breakdown on how these different timescales work together:

Run Time: This is the total time for which the experiment or the simulation will run. In this case, it's 5 minutes.

Loops: This is the total number of loops the script will run. Here, loops = 60*run_time, so if run_time is 5 minutes, loops will be 300. This means the script will run 300 cycles. It's important to note that in this context, each cycle corresponds to a second, as the run_time is converted to seconds by multiplying it with 60.

m.time: This is the prediction horizon in the model predictive control. It is discretized into 31 points from 0 to 30 seconds. The controller will generate a control plan for this entire prediction horizon at every cycle of the script.

Here's how all of these work together:

At each cycle (300 in total), the script will measure the current temperature, then solve the MPC problem to generate a control plan for the next 30 seconds (the prediction horizon). However, it will only implement the first second of this plan (first step of m.time), then it will measure the temperature again, solve the MPC problem again, and so on.

So, in essence, the control and prediction horizons are not longer than the discretization of the variables. The control plan is updated every second (each loop cycle) using the latest measurements.

This method is known as receding horizon control strategy, where the control action is re-computed at each time step, considering the current state of the system.

It's important to understand that the prediction horizon (m.time) does not need to be the same as the run time of the script. The prediction horizon just needs to be long enough to predict the future behavior of the system accurately, and it's often much shorter than the total run time of the experiment or the simulation.

Thanks,

Adnan

[Buddi]

Thanks a lot Adnan.

I appreciate your explanation. 

Best regards

Buddi

--
--
APMonitor user's group e-mail list.
- To post a message, send email to apmo...@googlegroups.com
- To unsubscribe, send email to apmonitor+...@googlegroups.com
- Visit this group at http://groups.google.com/group/apmonitor
---
You received this message because you are subscribed to the Google Groups "apmonitor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apmonitor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/apmonitor/4751f8e6-8b54-4c3f-a59b-569be438261en%40googlegroups.com.

[Charitha Buddhika Heendeniya]

I have a related question. I want my controlled variable to reach a target value after 1hour. 

But to keep the controller fast, I define my prediction horizon as 5mins, control horizon as 1 min, and time step as 1 second. 

Now I have a problem because I cannot add a hard constraint to guarantee the value of the controlled variable at the end of the simulation period, which is 1 hour. 

At best, I can use the set point in the objective function, but that results in a fast response early in the simulation because the error at the beginning is high. 

But instead, there might be a better solution (think about an economic MPC with a time-varying price) if the controller waits for a while and then start to take control actions. 

Does that mean MPC controllers are not suitable for this kind of optimal control or there is a work around to address such cases?

Regards

Buddi