Arrival and Departure nodes
We had to postpone Arrival and Departure nodes until now, because discussion of entities had to precede discussion of these special nodes. We have also weaved into this chapter the topic of creating the CostPerPiece curve, which we had deferred earlier in Chapter 5 (Execution of Network Type nodes).
 |
Close Figure 8 and Figure 9
windows if they are open. Click Figure 10 to open a
window showing an updated version of our example model. Notice that we have added
a[15] originating at n[5] and
terminating at n[2]PiecesPerHour to loop through the calculations to generate
x-y points for the CostPerPiece curve.
We have also changed the Type property of n[2]PiecesPerHour to Arrival and n[5]CostPerPiece to Departure. Arrival nodes cause creation of new Token entities and Departure nodes cause their disposal. |
|
Figure 10 |
There are many ways we can generate x-y pairs to build the CostPerPiece curve. We have chosen to create new arrivals to loop through and gather figures for the CostPerPiece curve merely to demonstrate what Arrival and Departure nodes do and how they relate to Token and Surrogate entities.
Recall that we already have a model showing what constitutes CostPerPiece. What we are doing now is creating a curve showing CostPerPiece as a function of PiecesPerHour. To do that we are now going to model the different pieces-per-hour values as different customers coming into our system/our service facility (i.e. the model) and departing after causing the creation of consequential costs per piece.
In Chapter 7 (ORMSware entities) we discussed how NMOD creates a default token with Token ID of 0 at the start of model run, and assigns it to Customer with default ID of 0. All surrogates created with no specific assignment to a token are automatically assigned to this default Token.
When a surrogate enters an Arrival node, NMOD creates a new Customer ID equal to 1 greater than the highest Customer ID in existence. It then fetches an unassigned customer token, or creates a new one if all existing ones are in use, and assigns it to the newly arrived customer.
When a customer leaves a network upon finishing a Departure node, the token is returned for reuse by future customers. NMOD also switches the Token ID of the surrogate representing that customer at the Departure node to the default Token ID of 0.
|
Note:
If there are Arrival nodes in a network, there must be at least one Departure
node for customers to leave the system. Otherwise, each arrival will stay
in the system, retaining a piece of
computer memory (space for Customer Token properties, and for properties of
related surrogates). If the number of arrivals is sufficiently large, a
model can cause out of memory condition unless there is at least one
Departure node for the arrivals to leave the system being modeled. This is comparable to memory leak in programming, but a much easier problem to detect. Problems of missing Departure nodes always surface quickly during early stages of model development, since in virtually every problem with customer arrivals there are natural matching departures that would be hard to miss. Also, at every Departure node NMOD checks the Surrogate Count property of the token being returned to make sure there are no stray surrogates associated with that token still remaining in the system. If there are, NMOD issues a warning before continuing execution. |
A surrogate is always related to a token. Default Token ID of a surrogate is 0. For example, as explained earlier, when NMOD creates the very first surrogate to be placed on the Start node of a model, that surrogate's Token ID is set to the default value of 0.
When a surrogate enters an Arrival node, it triggers NMOD's Arrival procedure. For the very first Arrival node occurrence, if the Surrogate ID is (say) 4 with default Token ID and default Customer ID, the surrogate's Name will be S4-T0-C0. When S4-T0-C0 evokes the Arrival node, NMOD does the following:
- Checks the highest Customer ID assigned so far, increments it by 1, and
assigns that value to the newly arrived customer. In our example problem,
the first time a surrogate enters the Arrival node, the newly created customer
is given the ID of 1 and is given the name C1.
- Either creates a new token, or gets a previously created token for reuse.
Continuing with our example above, since there are no previously
created tokens for reuse, NMOD creates a token and gives it an ID of 1.
Thus, the token's Name becomes T1-C1.
- Sets Surrogate 4's Token ID property value to 1. Thus, the surrogate's Name changes from S4-T0-C0 to S4-T1-C1.
NMOD maintains a linked-list to track existing tokens. The token that will be available to the next customer will always be the token that was returned most recently by a previous customer. If all previously created tokens are in use, NMOD creates a new token for the new customer.
| Note: Knowing such technical details is not necessary to start using NMOD. However, they are handy while debugging models during development. Analysts can also leverage knowledge of these details at times to develop clever models without sacrificing clarity and transparency, which are two key factors that motivated the creation of ORMSware. |
NMOD also maintains a similar linked-list to track existing surrogates. If there are previously created surrogates not in use whenever a surrogate is needed, the most recent surrogate that came out of circulation will be the one that is called in for action. It may be assigned to a token, or its Token ID property may be given the default Token ID of 0.
When a surrogate finishes a Departure node, the implication is that its customer is leaving the system. But, before leaving the system, the customer returns the token it was given when it entered the system. At that point, NMOD does the following:
- Switches the Token ID property of the surrogate to 0.
- Checks Surrogate Count property of departing customer's token and issues a warning if there
are stray surrogates still assigned to that token.
- Points the head of linked-list of tokens to the token being returned; newly-returned token in turn points to the token that was previously at
the head of the linked-list of tokens.
- Executes SignalTarget property of the Departure node.
| Note: That SignalTarget property is not executed until after Departure procedure is executed is critical. If a Departure node's SignalTarget property is executed before the Departure procedure, a customer that is supposed to have departed could show up later due to some event created by its SignalTarget property. If this does not quite sink in right now, do not be concerned. It will become obvious as you formulate a few problems with NMOD. |