Courses: Introduction to GoldSim:

Unit 7 - Modeling Material Flows

Lesson 14 - Unit 7 Summary

In this Unit, we discussed how to track the movement or changes in tangible things (such as water, widgets or people).  When tangible things move through or change within a system, the dynamics can actually be conceptualized in two different ways: continuously or discretely. Things that move continuously can be thought of as flowing.  An example of this is the movement of water.  Other things move or happen discretely (e.g., such that they must be tracked individually).  Examples of this include financial transactions or the movement of parts through a factory. Most real-world systems are best described using a combination of continuous and discrete dynamics. In this Unit, however, we focused on representing continuous dynamics.  A later Unit will focus entirely on GoldSim’s capabilities for representing discrete dynamics.

The key points that we covered were as follows:

  • Many elements in GoldSim actually have multiple outputs. The Reservoir is one such element. The output with the same name as the element is referred to as the primary output.  Other outputs are referred to as secondary outputs.
  • Not all elements, however, have a primary output.  A primary output represents the key output (i.e., the output that you are likely most interested in). For some elements, all the outputs are secondary outputs.
  • When we write expressions or reference another element name in an input field, we are not really referencing the name of the element at all; we are referencing the name of the element’s primary output.
  • To reference a secondary output, you need to reference both the element name and the output name as follows: ElementID.OutputID. 
  • If you specify an Upper Bound for a Reservoir, it adds two secondary outputs: 1) The Overflow_Rate outputs the rate the Reservoir is overflowing (and is zero unless the Reservoir is at its Upper Bound); 2) The Is_Full output is a condition.  It is True when the Reservoir is at the Upper Bound, and False otherwise.
  • GoldSim steps through time in discrete intervals referred to as timesteps. Calculations (referred to as updates of the model) are carried out at end of every timestep. In GoldSim, there are actually two kinds of updates/timesteps: scheduled updates and unscheduled updates.
  • Scheduled updates are specified directly prior to running the model.  That is, you tell GoldSim when you want these updates to occur. In some cases, however, certain events may occur between scheduled updates of the model, and waiting for the next scheduled update could decrease the accuracy of the simulation. Such events trigger what is referred to as an unscheduled update of the model.  Unscheduled updates are timesteps that are dynamically inserted by GoldSim during the simulation in order to more accurately simulate the system.
  • One of the most common events which can trigger an unscheduled update is a Reservoir hitting an Upper or Lower Bound.
  • A key and important difference between scheduled updates and unscheduled updates is that scheduled updates are included in time history plots and tables (unless you specifically choose to exclude some by skipping them).  Unscheduled updates, however, do not appear in time history plots and tables.  That is, although these timesteps may affect the results (e.g., by making them more accurate at the scheduled timesteps), unscheduled updates of the model are not saved or plotted.  Only the scheduled updates are actually saved and plotted.
  • Due to the possible presence of unscheduled updates, you should keep two things in mind: 1) You should never assume that the timestep length is constant.  It might actually change (shorten) during the simulation (due to unscheduled updates that you are unaware of); and 2) the value of an output reported at a particular time represents the instantaneous value at that point in time, and does not represent the average value over the previous timestep.
  • Reservoirs have an output named “Withdrawal_Rate”. This is not the same as the Withdrawal Rate input. The Withdrawal Rate input is what you wish to withdrawal from the Reservoir (it is a demand or a request).  The “Withdrawal_Rate” output is what is actually withdrawn from the Reservoir (which may be less than the request).  In particular, if the Reservoir is above its Lower Bound, the “Withdrawal_Rate” output is identical to the Withdrawal Rate input. However, if the Reservoir is at its Lower Bound, the “Withdrawal_Rate” output may be less than the Withdrawal Rate input.
  • When simulating the flow of materials (such as water or money or people) through a system, it is almost always necessary to split a flow at a particular point and redirect it to multiple destinations. Because this is so common, GoldSim has a specialized element to facilitate this named a Splitter.
  • In some situations, however, it is not possible to simply specify how a signal (a flow) is split.  Instead, there may be multiple competing “demands” on that flow and the total demand may exceed what is available.  In such a case, the flow must be allocated between those demands, based on priority. GoldSim provides a specialized element to facilitate this named an Allocator.
  • It is also common to need to sum a number of flows. The Sum element provides an easy and clear way to add together any number of flows (or other types of variables).
  • Although Reservoirs are useful for simple models (and some specialized applications), correctly modeling multiple withdrawals from a Reservoir can be complex (and require additional logic).  As a result, GoldSim provides a more powerful version of a Reservoir called a Pool.  A Pool combines the features of a Sum, an Allocator and a Reservoir into a single element. It is particularly powerful at allocating and routing multiple (and potentially competing) outflows. In most real-world cases you will want to use Pool elements whenever modeling material flows.

Now that you understand the fundamentals of modeling material flows, we can start to explore how to represent some of the complex dynamics that often occur in such systems, such as feedback loops and delays. We will start to do that in the next Unit.