Lesson 10 - Using Feedback Control and Allocation to Realistically Represent Outflows

Now that we have covered the use of the Status element for representing feedback control, we are finally ready to complete a discussion regarding the representation of outflows from a stock of material that we started in Unit 7 (Lessons 11, 12 and 13), touched on once more in Unit 8 (Lesson 7), and revisited again in the previous Lesson.

In the Exercise in the previous Lesson, we examined a feedback control problem in which the goal was to control a state variable (i.e., the water volume) around a particular “target” level.  We accomplished this by implementing a dead band using a Status element.

Although this is a common objective (e.g., a thermostat does this), it is also quite common for feedback control systems to be used to control the behavior of a system as it approaches its physical bounds (e.g., controlling the pumping rate to or from a pond as it approaches its upper limit or as it empties). One way to do this, of course, would be simply to have your “band” adjacent to the bound (e.g., turn a pump off when the volume reaches 0 m3 and turn it back on when the volume reaches, say 5 m3).

However, some systems may not work in such a binary manner.  Instead, they may gradually adjust flows as the volume approaches the bounds.  For some flows, this could happen naturally (e.g., as the volume decreases, the surface area decreases, and hence the evaporation rate decreases, going to zero as the volume goes to zero).  In other cases, you might intentionally slowly adjust the flows as you approach a bound (e.g., decreasing a pumping rate gradually as the volume approached zero).

In addition, as we saw in Unit 7, Lesson 13, in a situation where the outflows from a stock of material must be constrained (because Requested Outflows exceed Inflows, and the stock is at its lower bound), it becomes necessary to prioritize and allocate any remaining (i.e., non-zero) Requested Outflows.  We saw that a Pool element supports such prioritization.

In many systems, in order to be realistically represented, different outflows would likely need to be treated in different ways as the bound is approached: some would need to be turned on and off using a dead band, others would need to gradually be changed, and others would need to be prioritized (and hence reduced perhaps) once the bound is reached (and outflow is constrained). To illustrate this, in this Lesson, we are going to look at an Example that deals with multiple outflows, each of which needs to be represented differently. 

The model can be found in the “Examples” subfolder of the “Basic GoldSim Course” folder you should have downloaded and unzipped to your Desktop.  In that folder, open a model file named Example20_Multiple_Outflows.gsm.  The model looks like this:

The model is relatively complex compared to the Exercises we have done, but is still quite simple.  It utilizes some Containers to organize the model.  The model simulates a pond that has an initial volume of 200 m3 with a constant inflow (10 m3/day).  It has five outflows:

• Water evaporates from the pond.  The rate of evaporation is proportional to the pond surface area.  The surface area is a function of the pond volume (and this relationship is represented by a Lookup Table).  The Evaporation_Calculations Container contains the elements that compute the evaporation.  If you explore that Container, you will see that this is the identical structure that was used in Exercise 8 (Unit 8, Lesson 6).  The evaporation goes to zero as the volume goes to zero.  This is an example of a passive (natural) feedback control mechanism.
• Pump1 turns off (and on) according to a dead band. It initially pumps at a constant rate (of 20 m3/day).  However, it is switched off when the pond volume decreases to a certain level (100 m3).  If the pond volume were to rise (above 110 m3) it would turn on again.  The Pump1_Off_at_100 Container contains the elements that control the pumping rate.  If you explore that Container, you will see that this is the identical dead band structure (utilizing a Status element) that was used in the previous Lesson. The pumping rate becomes zero well before the pond volume reaches zero. This is an example of an active feedback control mechanism utilizing a dead band.
• Pump2 ramps down gradually. It initially pumps at a constant rate (of 20 m3/day).  However, it starts to smoothly ramp down when the pond volume decreases to a certain level (100 m3).  In particular, below a volume of 100 m3, the pumping rate is a function of the pond volume (and this relationship is represented by a Lookup Table). The Pump2_Ramps_Down Container contains the elements that control the pumping rate.  If you explore that Container, you will see the simple structure (utilizing a Lookup Table element) that is used to control the pumping rate. The pumping rate goes to zero as the volume goes to zero.  This is another example of an active feedback control mechanism.  Instead of using a dead band to switch on and off, the rate is gradually and smoothly adjusted.
• Pump3 and Pump4 are defined using constant Outflow Requests (of 8 m3/day).  As a result, no explicit measures are taken to reduce their values when the pond volume goes to zero. However, if the pond goes empty, the total outflow must be constrained (it could not be greater than the inflow, which is 10 m3/day). In this case, the actual outflows for Pump3 and Pump4 must be adjusted.  Physically, this is equivalent to saying that when the outflow becomes constrained, we will instantaneously adjust Pump3 and Pump4 accordingly. In order to do so, of course, we need to define some priorities.  Conceptually, this too is a form of feedback control (the actual pumping rates are reacting to the pond volume), but it is done internally to the Pool element, so it is not as evident.

Let’s look at the Outflows tab of the Pool representing the pond:

We know from the discussion above that the evaporation, Pump1 and Pump2 are all zero when the pond volume goes to zero.  But that is not the case for Pump3 and Pump4.  The Outflow Requests are constant, and hence if the pond goes to zero (and as we shall see, it does), those two flows need to be constrained. As can be seen here, Pump3 has a higher priority than Pump4.  (The priorities of the other Outflows are lower, but their priorities are inconsequential, as their Requests are all zero if the outflow becomes constrained.)

Run the model and display the results (by double-clicking on the Time History Result element):

The pond volume is plotted on the left-hand axis (it is a thick red line), and all of the flows are plotted on the right-hand axis. Note that the pond volume goes to zero just before 8 days.  Let’s examine the five outflows:

• The evaporation gradually decreases with the pond volume, going to zero when the pond volume goes to zero.
• Pump1 turns off (suddenly) when the pond volume reaches 100 m3.
• Pump2 gradually decreases with the pond volume once it drops below 100 m3, going to zero when the pond volume goes to zero.
• Pump3 stays constant during the entire simulation.  Pump4, however, immediately drops from 8 m3/day to 2 m3/day when the pond goes empty.  This is because the outflow becomes constrained, and Pump3 has a higher priority than Pump4.

This is obviously a simplistic and artificial example, but is serves to illustrate the different ways that you can use feedback control and the allocation/prioritization capabilities of the Pool element to represent multiple (and potentially competing) outflows.

The key point that you should take away from this discussion is that when building a model that involves outflows that have active or passive feedback control, it is critical for you have a very good understanding of how the real system actually works such that you represent realistic control systems in your model (i.e., systems that could be practically implemented). Otherwise, your simulated predictions will behave unrealistically and/or be of very limited value.