# Flow Prioritization

In the software, certain stock/flow configurations will cause stocks of various types to exert control over their flows. With multiple flows, the stock's control over its flow necessitates a Prioritization scheme. When multiple flows are involved and prioritization is an issue, an inflow and outflow priority number will appear in the dialog for each flow. This section provides an in-depth look at the control and prioritization rules the software uses for:

- Outflows from a Reservoir when non-negative is activated

- Inflows to an Inflow limited Conveyor

- Inflows to a Capacity-constrained Conveyor

- Inflows to a Queue

- Outflows from a Queue

We'll look at each in turn.

Non-negativity and Reservoir Outflow Prioritization:

When the Non-negative option is checked in the Reservoir dialog, the explicit logic of outflows will be overridden whenever it will otherwise cause the Reservoir's magnitude to become negative. In the simple case, with only one outflow from a Reservoir, the non-negative logic says that whenever the magnitude of the Reservoir, plus the total inflow over the next DT, is insufficient to support the explicitly-calculated outflow over the next DT, flow the entire magnitude of the Reservoir, plus the inflow, during a single DT. Internally, the software uses a calculation of the form:

outflow volume = MIN(Reservoir/DT +
total inflow volume, explicit outflow volume)

With multiple outflows, the non-negative logic gets a bit trickier. Essentially, the Reservoir will apply the non-negative logic to each outflow as it apportions its contents among the outflows. The apportionment is done on a priority basis, each DT in the model simulation. The priority 1 outflow gets first crack at the contents of the Reservoir. What's left over in the Reservoir (if anything), gets allocated to the priority 2 outflow. What's left after priority 1 and priority 2 have had their turn is allocated to the priority 3 outflow, etc.

The assignment of priorities for multiple outflows is determined primarily by the inner workings of the software. However, when there are interdependencies among the flows, the flow priority will reflect the dependency relationship. Any outflow whose volume depends upon the calculation of another outflow from the same Reservoir will assume a lower priority, as shown in Figure 14-4.

Figure 14-4 Non-Negativity and Reservoir Outflow Prioritization

######
Inflow Limited Conveyors and Inflow Prioritization:

In Conveyors, a finite Inflow limit can constrain inflows. The Inflow limit field is disabled whenever a Conveyor has inflows emanating from either another Conveyor or from an Oven. When inflows come from Reservoirs, clouds, or Queues, however, the Inflow limit may be set to a finite value. The underlying Inflow limit logic works in one of two ways, depending upon whether the "Discrete" check box is checked in the Conveyor dialog.

Case 1: Discrete is not checked in Conveyor dialog (possible with cloud and/or Reservoir to Conveyor flows only).

When the inflows to the Conveyor come from clouds and/or Reservoirs only, and the "Discrete" box is not checked, the Inflow limit will ensure that the total flow volume into the Conveyor will never exceed the limit. This means that the explicit inflow logic will be overridden whenever it yields a volume that exceeds the Conveyor's Inflow limit. For Reservoir to Conveyor or cloud to Conveyor flows, the Inflow limit is equivalent to the following:

flow volume = MIN(Inflow limit, explicit inflow volume)

Each DT in the simulation, the software will check to ensure that the explicit flow volume does not exceed the Inflow limit. If it does, the total inflow will be "clipped" to the value that you have set for the inflow limit.

The software will prioritize multiple inflows from clouds and/or Reservoirs to an Inflow-limited Conveyor. The first priority inflow gets first crack at the Inflow limit. Any remaining space gets allocated to the second priority inflow, and so on. Priority is established by the order in which inflows are created. The priority of flows is the order they were connected to the Conveyor. As with outflows from Reservoirs, the prioritization is altered to reflect dependency relationships among inflows to a given Conveyor. Figure 14-4 shows how a dependency between flows will change the prioritization of the flows.

Case 2: Discrete is checked in Conveyor dialog (optional with cloud and/or Reservoir to Conveyor flows only; set as the default when Queue to Conveyor flows exist).

When "Discrete" is checked, the Inflow limit will ensure that no more will flow into the Conveyor in a given unit of time than you have specified in the Inflow limit box. The software will keep track of how much has flowed into the Conveyor over the unit of time. If the total inflow volume would otherwise cause the Inflow limit to be exceeded, it will be "clipped" to the appropriate value. Each unit of time (i.e., at time = 1, time = 2, etc.) the internal tracking mechanism will reset itself.

Special Notes on Queue to Conveyor flows:

- Whenever a flow runs from a Queue to a Conveyor, the "Split batches" option becomes enabled. Split batches enables the Conveyor to chip away at the next element in the Queue, taking only what's needed to satisfy the Inflow limit constraint. If Split batches is not checked, the Conveyor has the potential to become gridlocked whenever the next element in the Queue is larger than the Inflow limit. To prevent gridlock, either designate a second outflow from the Queue as an "Overflow," or ensure that Split batches is checked in the Conveyor dialog.

- Whenever multiple flows come into a Discrete, Inflow-limited Conveyor, prioritization is required. The prioritization scheme used by the software is essentially the same as described on the previous page for non-discrete, Inflow-limited Conveyors. However, whenever a flow exists from a Queue to a Conveyor, it will always assume top priority. Subsequent flows from Queues will be prioritized in their order of creation.

######
Capacity-Constrained Conveyors and Inflow Prioritization:

In Conveyors, a finite Capacity can constrain inflows. The Capacity field is disabled whenever a Conveyor has inflows emanating from either another Conveyor or from an Oven. When inflows come from Reservoirs, clouds, or Queues, however, the Capacity may be set to a finite value.

In words, a Capacity-constrained Conveyor will ensure that the total inflow to the Conveyor will never cause the magnitude of the Conveyor to exceed the Capacity you have set. Flow logic will be overridden whenever nominal inflow volume (i.e., what "wants" to flow from clouds, Reservoirs and Queues) would cause Capacity to be exceeded. Internally, the software uses equations of the form:

inflow volume = MIN((Capacity - Conveyor)/DT +
total outflow volume, explicit inflow volume)

Each DT in the simulation, the software will check to ensure that the nominal inflow volume will not cause the capacity to be exceeded. If it will, the total inflow will be "clipped" to the appropriate value.

Special Note on Queue to Conveyor flows:

- Whenever a flow runs from a Queue to a Conveyor, the "Split batches" option becomes enabled. Split batches enables the Conveyor to chip away at the next element in the Queue, taking only what's needed to satisfy the Capacity constraint. If Split batches is not checked, the Conveyor has the potential to become gridlocked whenever the next element in the Queue would cause the Conveyor to exceed its Capacity constraint. To prevent gridlock, either designate a second outflow from the Queue as an "Overflow," or ensure that Split batches is checked in the Conveyor dialog.

The software will prioritize multiple inflows from clouds and/or Reservoirs to a Capacity-constrained Conveyor in the same way that it prioritizes flows under Inflow limits. As with Inflow-limited Conveyors, a Queue to Conveyor flow will always have a higher priority than a cloud or Reservoir to Conveyor flow.

######
Inflows to a Queue:

In the simple case with one inflow to a Queue, the Queue will create a new element or slot each DT to hold the inflow. With multiple inflows to the Queue, however, the software must create multiple slots - one for each of its inflows. The software prioritizes the inflows to a Queue to resolve the issue of which flow gets to enter the Queue first, in a given DT. As with inflows to Conveyors, prioritization is established by order of flow creation. The prioritization is altered to reflect implicit and explicit dependency relationships in the model. Queue outflows to the Queue will always be of highest priority, in their order of creation. A Conveyor leakage flow will always have higher priority than the flow-thru from the same Conveyor, when both flow into the same Queue. A flow whose calculation depends upon another flow will always have a lower priority than that other flow, when both flow into the same Queue.

######
Outflows from a Queue:

When multiple outflows are attached to a Queue, the software must first prioritize the outflows to resolve the issue of which flow gets to leave the Queue first, within a given DT. Once again, the priority is based on the order of creation. The first outflow created gets to flow first. What's left in the Queue (after the first flow has been calculated) is then available to the second flow that was created, etc.

Given the flow prioritization, the software uses the following control rules to determine the volume of each flow, each DT:

- Queue to Oven: Flow logic is controlled by Oven.

- Queue to Conveyor: Flow logic is controlled by Conveyor.

- Queue to Reservoir: Flow entire contents of Queue, plus whatever is flowing into the Queue - material will pass through the Queue.

- Queue to Cloud: Flow entire contents of Queue, plus whatever is flowing into the Queue - material will pass through the Queue.

- Queue to Queue: Flow next element in Queue, plus whatever is flowing into the Queue - material will pass through the Queue.

######
The Bottom Line

In terms of flow control and prioritization, the important information will be displayed to you within the flow dialogs. When relevant, the flow dialogs will tell you both the outflow and inflow priority of a given flow. In many cases, this can be overridden by making explicit dependencies between flows.