Lesson 3 - How Does GoldSim Handle Loops?
As pointed out in the previous Lesson, simple models have a direct chain of causality: input data affect some elements, which affect other elements, and so on, until eventually the elements which calculate the desired results of the model are reached:
In order to correctly calculate this, GoldSim automatically analyzes your entire model to identify "who affects who" to ensure that the "upstream" elements are calculated prior to the "downstream" elements. This is referred to as the causality sequence. At each timestep the elements are updated in this causality-based sequence.
Now let’s imagine that the system we are modeling has a looping structure. In fact, let’s try to build one now. Start with a new model, and do the following:
- Create an Expression named A. For now, let it simply be defined as 0.
- Create an Expression named B, equal to 2*A.
- Create an Expression named C, equal to 2*B.
- Now edit Expression A, and define it as 2*C (creating looping logic).
When you attempt this final step, you will see that GoldSim will display an error and will not allow you to “close” this loop:
It reports that there is an error because making this link “would create a recursive loop”.
Yet we discussed in the previous Lesson that GoldSim does in fact allow you to create feedback loops. So what is happening here? The problem is that this structure does not represent a feedback loop; it represents a recursive loop (which is not the same thing).
Let’s try something different now. Create a new model, and do the following:
- Create a Pool named Pond, and give it Quantity Units of m3 and Flow Units of m3/day.
- Give the Pool an Initial Quantity of 100 m3.
- Create an Expression named Evaporation, give it Display Units of m3/day, and define it as “10%/day * Pond”.
- Edit the Pool again, and enter “Evaporation” as the Request on the Outflows tab.
When you do so, your model will look like this:
Note that it looks like there is a double-headed arrow (influence) between Pond and Evaporation. Actually, this is not a double-headed influence at all. There are actually two influences sitting right on top of each other. If you left-click on the double-headed arrow, a point will appear in the middle. Select it (by left-clicking) and drag it (while holding the left mouse button down). You will then see that there are in fact two influences. You can drag the other one in the opposite direction so it looks like this:
As can be seen, there is a loop in the logic. GoldSim had no problem creating this loop. Why? Because this structure does represent a feedback loop. It is structurally different from a recursive loop.
How is this system structurally different from the one that produced an error? GoldSim allows you to create looping systems like this if and only if the following requirement is met: the loop must contain a state variable. The presence of a state variable in the structure indicates that the loop is a feedback loop. Without a state variable, it is a recursive loop (and the loop cannot be logically “closed”).
So what is a state variable? Within a GoldSim model (actually, any dynamic model), there are fundamentally two types of outputs:
- Outputs whose current value only depends on the current value of their element’s inputs ((i.e., they have no “memory”).
- Outputs whose value is computed based on the historical value of the element’s inputs (as opposed to being a function of the current value of the element’s inputs). These outputs can be thought of as having “memory” of what has happened before. The primary output of a Pool (or a Reservoir) is a classic example.
This second type of output is referred to as a state variable in GoldSim. Practically speaking, state variables are typically the key system variables that you are interested in predicting. Together, the state variables define the predicted state of the system at any time in the future. Examples of state variables include the volume of water in a pond, the amount of money in an account, the number of widgets in a warehouse, the status (on/off/failed) of a piece of equipment, and the public’s current perception of the quality of a product.
All state variables have, by definition, an initial value (e.g., for Pools and Reservoirs, we have seen that the initial value is explicitly specified). This allows the outputs to be computed when there are no historical input values available (e.g., at the start of simulation).
The most common state variable you will encounter is the primary output of a Pool (or Reservoir). A number of other elements, however, also have outputs which are state variables. The icons for state variables are highlighted in browsers (e.g., output ports):
State variables are identified in browsers by the vertical line to the left of the output symbol. In this example, Pool1 (the primary output) is a state variable.
How does GoldSim compute the causality sequence in the feedback loop shown above (Pond and Evaporation)? That is, in what order does it do the calculations?
In simplified terms, every timestep, GoldSim carries out its calculations as follows (in a manner that is referred to as an explicit solution to the governing equations):
- At time 0 (before the simulation begins):
- GoldSim obtains the initial value (defined by the Initial Quantity) for the Pond.
- It uses this value for the Pond to compute the Evaporation (at time 0).
- At timestep #1 (i.e., the first update after time 0):
- GoldSim uses the Evaporation value from time 0 to compute the value for the Pond at timestep #1 (i.e., it assumes that over the first timestep, the Evaporation was equal to the value computed at time 0).
- It uses this new value for the Pond to compute the Evaporation at timestep #1.
- At timestep #2:
- GoldSim uses the Evaporation value from timestep #1 to compute the value for the Pond at timestep #2 (i.e., it assumes that over the second timestep, the Evaporation was equal to the value computed at timestep #1).
- It uses this new value for the Pond to compute the Evaporation at timestep #2.
- And so on…
Hence, we see that state variables allow a looping model to properly initialize itself and subsequently move from one timestep to the next. Without a state variable, these steps could not be logically carried out.
Note: These steps above are not only carried out during scheduled timesteps. They are also carried out during unscheduled timesteps that GoldSim automatically inserts to more accurately represent the system. (Recall that unscheduled timesteps were discussed in Unit 7, Lesson 4).
For the simple feedback loop shown above, the results would look like this:
You can walk through the steps above to confirm to yourself how GoldSim is computing Pond and Evaporation.
Note: If you run this model and your table shows a different number of significant figures, you can change this to see more or less. In particular, when viewing the table, you can press Alt-Right and Alt-Left to display more or less significant figures.
The brief discussion presented here was intended to give you a better idea of how GoldSim actually carries out its calculations. As discussed at the beginning of the Course, as a general rule, you should not use “black boxes” to build models. If you don’t understand how a tool works, you should not use it. If you are interested, you are encouraged to read more in GoldSim Help, where this topic is discussed in considerably more detail.
The discussion here was by no means complete, but it is sufficient for our present purposes. The key point for you to understand is that feedback loops include a state variable. If you try to create a looping system without a state variable, GoldSim will display an error message. In complex models, however, this is not an uncommon problem to encounter, and we will discuss this further (and how to address it) later in this Unit.