Initial values for MPC (model predictive control)

Question

Hello,

I intend to use a Model Predictive Controller with a simple TRNSYS model, a closed loop made of a tank + energy losses -> single speed pump -> heater with PID -> tank. The overall objective is to define the temperature set point for the PID so that the temperature at the outlet of the tank remains within a given range, which is time-dependent.

To achieve this, I am optimizing the temperature set point used in the PID by relying on a Matlab routine. However, I intend to run the optimization over a long time span of one month, which does not meet the requirements of the optimization algorithm due to the excessive time it would take. Therefore, the long time span has been divided into smaller problems of 24 hours each. The optimization is performed for the first problem (0-->24h) and then repeated for the subsequent ones (6->30h), etc., following the same procedure used for Model Predictive Controllers.

As can be seen, the time spans of the two problems overlap intentionally. The values from the first simulation are used as initial conditions to start the second simulation. This includes:

The temperature for each node of the tank.
The temperature at the inlet of each element.

The overall procedure involves pausing a large simulation and then restarting it (note that TRNSYS is opened / closed after each pause).

Problem

When running a single simulation that covers the entire time span, the results differ slightly from those obtained by running two simulations. A small error occurs at 6h, which is when the second simulation was started with new initial values. This error persists for the next 18h.

I am confident in the algorithm I am using, as it has been successfully tested with a state-space model in Matlab. In this scenario, the results were the same whether running up to 10 short simulations or a single large simulation. Therefore, I suspect an error in the way I am initializing values within TRNYS or some hidden calculations.

Question

Is there an efficient way to initialise TRNSYS for a problem like this?
Any help would be appreciated.

Sincerely

M.Labat

A_Weiss · Accepted Answer

My first thought is that you are probably using the average values from the final time step of the first simulation to set the initial values of the second simulation, whereas what you really want is the final values from the final time step of that first simulation. For most TRNSYS types, unless otherwise stated, the output from the Type at a given time step is the average value of that output over the preceding time step. For example, if a simple tank heats from 10 C at time=0 hr to 20 C after 0.125 hrs, the outlet temperature printed at time=0.125-hr will be the average outlet temperature between hour 0 and hour 0.125, or 15 C. This decision was made so that outputs connected as inputs to other Types will use average values to converge on a solution for the system over the time step. Internally, the Type does still calculate 20 C as its final temperature, and it will use that value as its initial value for the next time step. Unfortunately (for your purposes, at least), that final temperature is not made visible to the user for most Types.

My suggestions would be to either a) modify the tank Type to output both average and final temperatures at each time step, or b) use a debugging tool like Visual Studio to step through the code on the final time step, and manually mark down the final temperatures needed for the start of the next simulation. You can reduce the difference between average and final values by reducing the TRNSYS time step, so, it's also possible there's a suitably small time step for your purposes that the difference between average and final values is negligible.

As a side note, I am curious if you need the PID control at all? There are many simpler control strategies in TRNSYS to keep the outlet temperature of a tank within a given range. For example, you could connect the outlet temperature of the tank to a heating aquastat (Type 106) and connect its signal to the heater. This will give on/off control of the heater, not proportional control, but at a sufficiently small time step (usually 1 min or 5 min) you'll get behavior over time that's well representative of actual on/off heating elements. Type 108 is also a possibility, if there are multiple stages of heating available. There are also linear proportional controllers, time-delay staged controllers, ideal combination controllers, and others in the TESS Controllers library. The challenge with PID controllers in TRNSYS is that actual PID controllers make control decisions every second or so, and the typical time step for TRNSYS is on the order of 1 to 5 minutes or more - the longer the TRNSYS time step, the more the TRNSYS-modeled PID controller deviates from the hundreds of decisions an actual PID controller would have made in that time frame. You can run TRNSYS at a 1-second time step (and people have!), but that's not usually practical or suitable for most applications. All that to say, the TRNSYS PID model is not always the best controller to use in a TRNSYS simulation, even to represent control decisions that will ultimately be governed by PID controllers in the real world, so I like to explore other options first before settling on PID in TRNSYS as the way to go.