GoldSim 12 Preview (Part IV): The Pool Element

Posted by Rick Kossik

This is the fourth in a series of blog posts in which I briefly introduce many of the exciting new features that will appear in GoldSim 12 (the previous post can be found here). We plan to release GoldSim 12 in February 2017. Today's blog post focuses on a powerful new stock element: the Pool. A Pool is an expanded (and more powerful) version of the Reservoir element. It can do everything that a Reservoir can do, but has additional features to make it easier to manage multiple outflows (and inflows). As a result of these features, if you are modeling a system that has multiple distinct outflows, you should use a Pool rather than a Reservoir. In fact, we expect the Pool to replace the Reservoir for many types of applications (e.g., water management models).

A Pool can do everything that a Reservoir can do (e.g., it can have Upper and Lower Bounds), but is different (and hence more powerful) in three important ways:

• Pools allow you to specify Inflows as separate and individual inputs. (Reservoirs provide only a single input for inflows).
• Pools allow you to specify Requested Outflows as separate and individual inputs. (Reservoirs provide only a single input for a “withdrawal request”). In turn, in addition to providing a “total outflow” output, Pools provide separate and individual outputs for each requested outflow. (Reservoirs provide only a single “withdrawal rate” output). This allows you to easily route different outflows to different locations.
• Because Pools allow you to specify multiple Requested Outflows, and it is possible (if the Pool reaches its Lower Bound) that the Pool may not be able to provide the total for all requests, you also specify Priorities for each requested outflow, and the total outflow is then allocated accordingly among the requests if the Pool is unable to provide all of the requests.

The Pool dialog has three tabs.  In the default (Definition) tab, the Units, Initial Quantity, Lower Bound, Upper Bound and discrete Additions and Withdrawals are specified:

The Inflows tab is used to specify all of the individual inflows to the Pool:

More importantly, the Outflows tab is used to specify individual requested outflows from the Pool:

Pools have the following outputs:

• The quantity in the Pool (the primary output, having the same name as the element);
• The Total_Inflow to the Pool (simply the sum of all the Inflow inputs);
• The Total_Request from the Pool (simply the sum of all the Requested Outflow inputs);
• The Total_Outflow from the Pool (which is always less than or equal to the Total_Request); and
• Each individual Outflow from the Pool (whose names are user-defined).
• The Overflow from the Pool (only available if an Upper Bound is defined);
• Is_Full, a condition indicating whether or not the Pool is at its Upper Bound (only available if an Upper Bound is defined).

You can see these outputs here:

Note that all of the individual Outflows are separate outputs (contained in a folder above).  It is also important to note that the outputs names are user-defined. This is very powerful, because it allows you to easily route these outflows to different locations in a very transparent way:

For example, the Material Delay being used to model a pipeline connecting the pond to the mill would simply directly reference the Mill outflow output from the Pool:

Recall that a Reservoir has only a single “Withdrawal_Rate” output (identical to the Total_Outflow output for a Pool), so it makes it cumbersome to individually reference multiple outflows.  This problem is completely solved with the Pool.

GoldSim sums the individual Outflow Requests to compute the Total_Request output.  If the Pool stays above the Lower Bound (or there is no specified Lower Bound), then the Total_Outflow output is equal to the Total_Request. If the Pool reaches the Lower Bound, however, GoldSim compares the Total_Request to the amount of material available, and the Total_Outflow is computed such that it represents what can actually be withdrawn from the Pool at that time (which, depending on the Inflows, may be less than the Total_Request).

Note that if the Total_Outflow is limited (such that it is less than the Total_Request), and there are multiple Outflow Requests, it becomes necessary to allocate the Total_Outflow among the individual requests.  This is done based on the specified Priority for each Outflow Request.  The algorithm to do  is the same algorithm used by the Allocator element.  In fact, a Pool can be thought of as a combination of a Reservoir and an Allocator.