How a Pool Computes the Individual Outflows

GoldSim sums the 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 requests. This is done based on the specified Priority for each Outflow Request. Outflow Requests with lower valued Priorities are met first (i.e., Priority 1 is met before Priority 2).

The Total_Request output (the sum of the individual Outflow Request inputs) is 130 m³/day.

Let’s further assume that throughout the simulation, the Pool is always above its Lower Bound. In this simple case, the Total_Outflow output would be the same as the Total_Request output (130 m³/day). As a result, the Priority for each Request would never need to be considered (each individual outflow would receive its entire Request).

Now let’s complicate this example a bit more. Let’s assume that the Pool is empty (at its Lower Bound), but the Inflows to the Pool sum to 100 m³/day. In this case, since the Total_Request is equal to 130 m³/day, the Pool would remain empty (more is requested than in coming in, and there is nothing available from storage). Moreover, the Total_Outflow would be limited to 100 m³/day. As a result, it is necessary to allocate the Total_Outflow among the requests. This is done based on the specified Priority for each Outflow Request. Outflow Requests with lower valued Priorities are met first (i.e., Priority 1 is met before Priority 2).

In this case, Outflow1 would have a value of 75m³/day (its entire request would be met), Outflow2 would have a value of 20m³/day (its entire request would be met), Outflow3 would have a value of 5m³/day (only part of its request would be met), and Outflow4 would have a value of 0m³/day (none of its request would be met).

By default, each output has a fixed (and unique) Priority (which is an integer). The Priority of the outputs always decrease downward (with the first item having a Priority of 1). Priority 1 therefore represents the highest priority demand, 2 the next highest, and so on. You can move outflows up and down the Priority list using the Move Up and Move Down buttons.

If you check the Define Priorities checkbox, the Priority column becomes editable. In this case, the Priorities can be specified as constants or expressions and/or links, and may change with time. They do not need to be integers and can be any real value (positive or negative). Outflows with lower valued Priorities are met first (e.g., Priority -2.4 is met before Priority 5.7).

You can also assigned the same Priority to multiple Outflow Requests. If multiple Outflow Requests have the same Priority, you can specify the manner in which equal priorities are treated in the If equal field. There are two options: 1) “share equally”; or 2) “share proportional to requests”.

If “share equally” (the default) is selected, each Outflow Request with equal Priority receives the same amount up until either its request is satisfied, or nothing more is available. The calculation is carried out recursively starting with the smallest request.

Again, let’s assume that the Pool is empty (at its Lower Bound), but the Inflows to the Pool sum to 100 m³/day. In this case, since the Total_Request is equal to 110 m³/day, the Pool would remain empty (more is requested than in coming in, and there is nothing available from storage). Moreover, the Total_Outflow would be limited to 100 m³/day. As a result, it is necessary to allocate the Total_Outflow among the requests. Note, however, that the final three requests all have the same Priority.

In this case, Outflow1 would have a value of 75m³/day (its entire request would be met), Outflow2, Outflow3 and Outflow4 would share the remainder (25m³/day) as follows:

• Outflow4 would receive its full request (5m³/day); Outflow2 and Outflow3 would receive the same amount (5m³/day). This leaves 10m³/day to be allocated.

• Outflow2 and Outflow3 would then equally share the remaining 10m³/day (such that each would receive a total of 10m³/day). So Outflow3 and Outflow4 would meet their demands, and Outflow2 would not.

If “share proportional to requests” is selected, if there is not enough supply to meet all of the requests, it is shared proportionally according to the request.

To illustrate this, consider the same example as above, with proportional sharing:

In this case, Outflow1 would still have a value of 75m³/day (its entire request would be met), Outflow2, Outflow3 and Outflw4 would share the remainder (25m³/day) as follows:

The table below summarizes the results for these two examples (note that the Total_Inflow (and Total_Outflow) is 100m³/day and the Total_ Request is 110 m³/day):

Outflow	Priority	Request (m³/day)	Result with equal sharing (m³/day)	Result with proportional sharing (m³/day)
Ourflow1	1	75	75	75
Ourflow2	2	20	10	14.3
Ourflow3	2	10	10	7.1
Ourflow4	2	5	5	3.6

Note: The algorithm described above 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.