For all stocks other than reservoirs that are not marked non-negative, outflows are constrained by the stock value as well as (potentially) inflows. For stocks, such as ovens or conveyors, with limited capacity and rules about starting batches, inflows may also be constrained.
With multiple flows, the stock's control over its flows 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:
We'll look at each in turn.
When the non-negative option is checked in the stock dialog, the explicit logic of outflows will be overridden whenever it will otherwise cause the stock's magnitude to become negative. In the simple case, with only one outflow from a stock, the non-negative logic says: whenever the magnitude of the stock plus the total inflow over the next DT is insufficient to support the explicitly-calculated outflow over the next DT, then the outflow is the entire magnitude of the stock, plus the inflow, during that single DT. Internally, the software uses a calculation of the form:
outflow volume = MIN(stock/DT +
total inflow volume, explicit outflow volume)
With multiple outflows, the non-negative logic gets a bit trickier. Essentially, the stock will apply the non-negative logic to each outflow as it apportions its contents among them. The apportionment is done on a priority basis, once each DT in the model simulation. The priority 1 outflow gets first crack at the contents of the stock. What's left over in the stock (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 inter-dependencies 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 stock will assume a lower priority, as illustrated below.
Even in the simple case of a single outflow, the dependence of the outflow on the inflow can cause an implicit dependence. Consider the very simple example:
To keep the stock non-negative, the outflow will depend on the inflow. The inflow, however, already depends on the outflow explicitly. This is then a circular connection. To resolve this, the inflow isn't used to determine how much can flow out: only the value of the stock is. This can cause a delay between inflow and outflow, and so the stock is shown with the delay symbol ||.
The software will do this change automatically, and, in some cases, changing one stock means that others don't need to be changed, so it's not easily predicable which stock will be changed. If you uncheck the non-negative option for the stock, it will break such implicit dependencies and you may be able to prevent the required introduction of a delay.
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 stocks, 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 selected in the Conveyor dialog box.
Case 1: Discrete is not checked in conveyor dialog (possible with cloud and/or stock to conveyor flows only).
When the inflows to the conveyor come from only clouds and/or stocks, and the "Discrete" box isn't 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 stock-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've set for the Inflow Limit.
The software will prioritize multiple inflows from clouds and/or stocks 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 in which they were connected to the conveyor. As with outflows from stocks, the prioritization is altered to reflect dependency relationships among inflows to a given conveyor. The diagram under non-negativity above shows how a dependency between flows will change the prioritization of the flows.
Case 2: Discrete is checked in conveyor dialog (optional only with cloud- and/or stock-to-conveyor flows; set as 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've 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. For each unit of time (i.e., at time = 1, time = 2, etc.) the internal tracking mechanism will reset itself.
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 stocks, clouds, or queues, however, the capacity may be set to a finite value.
In other 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've set. Flow logic will be overridden whenever nominal inflow volume (i.e., what "wants" to flow from clouds, stocks 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:
The software will prioritize multiple inflows from clouds and/or stocks 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 stock-to-conveyor flow.
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.
You can, by setting an attribute value and selecting the option to prioritize inflows based on attributes, have inflows jump ahead in a queue (see Queue Computation). If you have not done that, or for inflows with the same priority, the sequence in which they are added to the queue is dependent on the order they are drawn.
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 to queues outflows 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.
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. You can explicitly control this using queue dispatch priorities (see Queue Computation) or allow the software to do it based on the order the outflows are drawn.
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:
Note If an oven is filling, it is given higher priority than an oven waiting to start filling.
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.