Implementing a Thermostat with the Events Interface

A thermostat is a device that senses the temperature of a system and uses this information to control the system’s heaters, or coolers, to keep the temperature close to a desired setpoint. While there are many different types of thermostats, we will focus today on one that turns a heater either on or off based upon two setpoints. This is known as an on-off or a bang-bang controller, and it can be implemented with the Events interface in COMSOL Multiphysics.

How Thermostats Work

Let’s consider a thermostat similar to the one that you have in your home. Although there are many different types of thermostats, most of them use the same control scheme: A sensor that monitors temperature is placed somewhere within the system, usually some distance away from the heater. When the sensed temperature falls below a desired lower setpoint, the thermostat switches the heater on. As the temperature rises above a desired upper setpoint, the thermostat switches the heater off. This is known as a bang-bang controller. In practice, you typically only have a single setpoint, and there is an offset, or lag, which is used to define the upper and lower setpoints.

The objective of having different upper and lower setpoints is to minimize the switching of the heater state. If the upper and lower setpoints are the same, the thermostat would constantly be cycling the heater, which can lead to premature component failure. If you do want to implement such a control, you only need to know the current temperature of the sensor. This can be modeled in COMSOL Multiphysics quite easily, as we have highlighted in this previous blog post.

On the other hand, the bang-bang controller is a bit more complex since it does need to know something about the history of the system; the heater changes its state as the temperature rises above or below the setpoints. In other words, the controller provides hysteresis. In COMSOL Multiphysics, this can be implemented using the Events interface.

Using the Events Interface to Control a Heater

When using COMSOL Multiphysics to solve time-dependent models, the Events interface is used to stop the time-stepping algorithms at a particular point and offer the possibility of changing the values of variables. The times at which these events occur can be specified either explicitly or implicitly. An explicit event should be used when we know the point in time when something about the system changes. We’ve previously written about this topic on the blog in the context of modeling a periodic heat load. An implicit event, on the other hand, occurs at an unknown point in time and thus requires a bit more set-up. Let’s take a look at how this is done within the context of the thermal model shown below.

Sketch of the thermal system under consideration.

Consider a simple thermal model of a lab-on-a-chip device modeled in a 2D plane. A one millimeter thick glass slide has a heater on one side and a temperature sensor on the other. We will treat the heater as a 1W heat load distributed across part of the bottom surface, and we will assume that there is a very small, thermally insignificant temperature sensor on the top surface. There is also free convective cooling from the top of the slide to the surroundings, which is modeled with a heat flux boundary condition. The system is initially at 20°C, and we want to keep the sensor between 45°C and 55°C.

A Component Coupling is used to define the Variable, T_s, the sensor temperature.

The first thing we need to do — before using the Events interface — is define the temperature at the sensor point via an Integration Component Coupling and a Variable, as shown above. The reason why this is done is to make the temperature at this point, T_s, available within the Events interface.

The Events interface itself is added like any other physics interface within COMSOL Multiphysics. It is available within the Mathematics > ODE and DAE interfaces branch.

The Discrete States interface is used to define the state of the heater. Initially, the heater is on.

First, we use the Events interface to define a set of discrete variables, variables which are discontinuous in time. These are appropriate for modeling on/off conditions, as we have here. The Discrete States interface shown above defines a variable, HeaterState, which is multiplied by the applied heat load in the Heat Transfer in Solids problem. The variable can be either one or zero, depending upon the system’s temperature history. The initial condition is one, meaning we are starting our simulation with the heater on. It is important that we set the appropriate initial condition here. It is this HeaterState variable that will be changed depending upon the sensor temperature during the simulation.

Two Indicator States in the Events interface depend upon the sensor temperature.

To trigger a change in the HeaterState variable, we need to first introduce two Indicator States. The objective of the Indicator States is to define variables that will indicate when an event will occur. There are two indicator variables defined. The Up indicator variable is defined as:

T_s - 55[degC]

which goes smoothly from negative to positive as the sensor temperature rises above 55°C. Similarly, the Down indicator variable will go smoothly from negative to positive at 45°C. We will want to trigger a change in the HeaterState variable as these indicator variables change sign.

The HeaterState variable is reinitialized within the Events interface.

We use the Implicit Events interface, since we do not know ahead of time when these events will occur, but we do know under what conditions we want to change the state of the heater. As shown above, two Implicit Event features are used to reinitialize the state of the heater to either zero or one, depending upon when the Up and Down indicator variables become greater than or less than zero, respectively. The event is triggered when the logical condition becomes true. Once this happens, the transient solver will stop and restart with the newly initialized HeaterState variable, which is used to control the applied heat, as illustrated below.

The HeaterState variable controls the applied heat.

When solving this model, we can make some changes to the solver settings to ensure that we have good accuracy and keep only the most important results. We will want to solve this model for a total time of 30 minutes, and we will store the results only at the time steps that the solver takes. These settings are depicted below.

The study settings for the Time-Dependent Solver set the total solution time from 0-30 minutes, with a relative tolerance of 0.001.

We will need to make some changes within the settings for the Time-Dependent Solver. These changes can be made prior to the solution by first right-clicking on the Study branch, choosing “Show Default Solver”, and then making the two changes shown below.

Modifications to the default solver settings. The event tolerance is changed to 0.001 and the output times to store are set to the steps taken by the solver.

Of course, as with any finite element simulation, we will want to study the convergence of the solution as the mesh is refined and the solver tolerances are made tighter. Representative simulation results are highlighted below and demonstrate how the sensor temperature is kept between the upper and lower setpoints. Also, observe that the solver takes smaller time steps immediately after each event, but larger time steps when the solution varies gradually.

The heater switches on and off to keep the sensor temperature between the setpoints.

Summary

We have demonstrated here how implicit events can be used to stop and restart the solver as well as change variables that control the model. This enables us to model systems with hysteresis, such as thermostats, and perform simulations with minimal computational cost.