One of the most powerful features of a Reservoir is that you can specify a Lower and/or Upper Bound. If the Lower Bound and Upper Bound boxes are cleared for a Reservoir, the Value is not constrained and is unbounded (as is the case for an Integrator).
Checking one or both of these boxes, however, provides additional functionality and has important impacts on the outputs for the element. In particular:
• If the Lower Bound is checked, GoldSim enforces that limitation on the Value. As a result, the Withdrawal_Rate output is not necessarily equal to the Withdrawal Requests/Rate of Change input. In this case, the Withdrawal_Rate output represents the actual rate of withdrawal from the Reservoir, which may be less than the specified Withdrawal Requests/Rate of Change (which represents the demand or requested rate of withdrawal).
For example, if the Reservoir is at the Lower Bound, and the Additions/Rate of Change is zero, the Withdrawal_Rate output must be equal to zero, regardless of the Withdrawal Requests/Rate of Change (there is no material available to be withdrawn). Similarly, if the Reservoir is at the Lower Bound, and the Additions/Rate of Change is equal to 10, the Withdrawal_Rate output can be no greater than 10, regardless of the Withdrawal Requests/Rate of Change (if there is no storage, you cannot withdrawal more than is being supplied).
By default, when you create a new Reservoir element, the Lower Bound is checked (and a value of 0 is assumed).
Note: If the Lower Bound is constant, the Value in the Reservoir will never fall below the Lower Bound. However, if the Lower Bound is changing with time, under some circumstances, it is possible for the Value of the Reservoir to fall below the Lower Bound. The primary purpose of the Lower Bound is to accurately compute the Withdrawal_Rate. If the Lower Bound exceeds the amount in the Reservoir (because the Lower Bound has changed during a timestep), the Reservoir will not permit any withdrawals until it returns to the Lower Bound (via additions).
Note: If you are modeling a system that has multiple distinct withdrawals (particularly if the Reservoir can reach its Lower Bound), you likely will want to use a slightly more powerful version of the Reservoir, referred to as a Pool.
• If the Upper Bound is checked, GoldSim enforces that limitation on the Value. GoldSim also adds two new (secondary) outputs: Overflow_Rate (a value) and Is_Full (a condition). If the Value is below the Upper Bound, the Overflow_Rate output is equal to zero and the Is_Full output is False. If the Value is at the Upper Bound, the Overflow_Rate output is equal to the difference between the specified Addition Rate and the specified Withdrawal Rate and the Is_Full output is True.
Note: If the Upper Bound is constant, the Value in the Reservoir will never exceed the Upper Bound. However, if the Upper Bound is changing with time, under some circumstances, it is possible for the Value of the Reservoir to exceed the Upper Bound. If the Upper Bound is exceeded (because it has changed during a timestep), GoldSim will overflow the excess uniformly over the next timestep.
Most real-world Reservoirs have such bounds. For example, many Reservoirs would have a logical lower bound of zero (e.g., a pond cannot contain a negative quantity of water, a parking lot cannot contain a negative number of cars). Many Reservoirs also have a logical upper bound (e.g., tanks and parking lots have maximum capacities). Some Reservoirs may have a lower bound, but no upper bound (e.g., a bank perhaps could not be negative, or at least there will be some limit on the amount that can be overdrawn, but would probably have no practical upper bound).
Note: If your specified Upper Bound is reached during a simulation, and the Overflow_Rate output is not referenced by any other element (e.g., as an inflow to another Reservoir), GoldSim will display a warning, as this could indicate that you have neglected to track flows leaving the Reservoir.
Note: GoldSim generates a warning message whenever a Reservoir reaches its Lower Bound such that the requested withdrawal cannot be delivered AND the Withdrawal_Rate output is not referenced by another element.
The Reservoir element is particularly powerful because it enforces the bounds while properly conserving the material being tracked. That is, if a Reservoir’s Additions/Rate of Change causes it to reach its Upper Bound, GoldSim produces an Overflow_Rate (which can be routed to a downstream Reservoir). Similarly, if you specify a Withdrawal Requests/Rate of Change that exceeds what can actually be delivered, GoldSim accurately reports the actual Withdrawal_Rate.
Furthermore, the Upper and Lower Bounds can be specified as functions of time. This allows you to simulate systems such as a pond which is filling up with silt and sand (and hence decreasing its capacity), and a warehouse whose capacity is being expanded (via construction) throughout a simulation.
The Lower Bound and the Upper Bound inputs to the Reservoir must have the same attributes (order and dimensions) as the Reservoir's primary output. In addition, the following limitations imposed on the inputs should be specifically noted:
• The Upper Bound must be greater than or equal to the Lower Bound.
• The Initial Value must be greater than or equal to the Lower Bound and less than or equal to the Upper Bound.
Note: If the output of a Reservoir is specified as being an array (a vector or a matrix), the Upper and Lower Bounds must, by definition, themselves be arrays. Because these fields are optional (you must check the box to activate them), if the box is selected, you cannot leave the field blank (like you can do for the Rate of Change inputs). For example, if you wish to specify a vector of zeroes (e.g., for the lower bound), you must do so by entering “vector(0)”.
Learn more about:
How a Reservoir Computes the Overflow Rate
Using the Is_Full Output of a Reservoir
How a Reservoir Computes the Withdrawal Rate