|
Objects in this document may appear out of sequence if not viewed with Internet Explorer |
|
ORMSwareTM Suite is a product of Ushar Enterprises Inc, Littleton, Colorado, USA |
|
Click to go to summaries of all examples and paths to Primer and Hands-on Tutorial |
|
A rental car company has three rental locations (bases) in a city. Customers may drop off rentals at any one of the three locations regardless of where they pick up the vehicles. This option causes fleet migration, changing the distribution of the fleet over time among the three bases. The company wants a model to predict where the vehicles will be at the end of each work week to plan how many vehicles must be moved form where to where. Later, the model is to be expanded to develop decision rules for when cars should be moved from one base to another based on various operational factors and nonlinear cost functions.
Notes
Formulation of this problem is more easily understood through its ORMSware network diagram and supplemental data files. Click the links below as desired to open these files in separate windows for reference while reading this document. VSD
file: Image of Visio network file describing the model Number of vehicles at any base B after the nth transition can be found by multiplying the number of vehicles at each base after the (n-1)th transition by the probability that they will transition to B, and adding up those results. For example, number of vehicles at the West location after the first transition will be {98*0.85 = 83.30} + {304*0.03 = 9.12} + {48*0.05 = 2.40} = 94.82. Thus, distribution of vehicles after the nth transition is the distribution vector of vehicles after the (n-1)th transition multiplied by the transition probability matrix. This core part of this model (see transition part in black & white section below) can be coded in Fortran 95 in a matter of minutes as shown below. Obviously, if this is all the company wants to find out every week, slight modification of the code below with a bit more flexibility will be sufficient to serve that purpose. However, if the company wishes to expand the model to incorporate other operational and service issues and strategic pricing, NMOD is likely to be a more desirable and faster model development tool.
This model has some similarities to Problem 1 in that it has a divergent node in a cycle (n[7]-{a[8],a[5],a[6]}-n[3]-{a[9],[10],[11]}-n[7]) spawning multiple calculation threads. However, the difference here is that the multiple entities created during a cycle are merged back into one entity by the last node (n[7]) in the cycle. Multiple arcs between same pairs of nodes (see arcs between n[7] and n[3]) are used to capture vehicles available at each base on a given day, and to calculate daily migration. For each calculation thread arriving at n[3] from n[7], three threads go from n[3] back to n[7], creating 9 threads in each transition cycle. Added advantage of modeling this problem in this manner is the ease with which complex cost functions can be incorporated into the model at a later stage for (say) moving vehicles from one location to another. Model execution starts at the Start node of the network, viz. n[2]Initializations located at the top left of the page.
The content of any node or arc in this model can be viewed by locating the object of interest in the model's NET file. Not every node and arc in the model's network(s) is listed in the NET file. Only nodes and arcs with user-defined content are included, since default content of every node and arc is known a priori and, therefore, is built into NMOD for automatic execution. n[7]Cars rented: This node sets things up for the next transition cycle. It sets the vector dblPreviouslyAt, which tracks the number of vehicles at every base at the end of previous cycle, equal to dblCurrentlyAt. dblCurrentlyAt is a vector used to accumulate transitions into each base from other bases during a day (cycle). Since dblCurrentlyAt is an accumulation vector for each cycle, n[7]Cars rented resets all of dblCurrentlyAt's elements to zero before launching a new cycle. {a[8],a[5],a[6]}Cars rented--->|Cars returned: An entity (calculation thread) arriving at n[7]Cars rented multiplies to three entities as it branches out along a[8], a[5] and a[6]. a[8] stamps entities traveling on it as vehicles located at the West base as a new cycle begins; a[6] stamps entities as vehicles located at the Airport base, and so on. n[3]Cars returned: Notice that there is no content for this node in the NET file. That is because the only function this node serves is to be a logical junction for allowing vehicles from any base to be returned to the same base or any other base. Thus, three entities entering n[3]Cars returned multiply to 9 entities, accounting for returns of vehicles from each of the three bases to any of the three bases.
Notice also that [9], [10] and [11] are AND arcs (see Type property in the dialog box image above and the corresponding double-headed arrows in the Visio diagram). Convergence requirement on an AND arc is 1 by default. If the convergence node at which an AND arc terminates has k AND arcs terminating at it in total, k calculation flows must arrive at that node to cause it to fire. In this case there are three AND arcs terminating at n[7]. So, the default convergence requirement will be 3. However, we needed to ensure that each of these three arcs received a flow from every base (i.e. 3 flows each, carrying vehicle movement from every base to every base) during a transition cycle. We could accomplish this in two ways as explained below (we have used both in the model for illustration purposes):
Click here to view a file containing the results calculated by this model to determine the location of vehicles at the end of 5 transitions (Monday-Friday). This problem can be restructured slightly, raising the level of abstraction by replacing the three arcs leading into and out of n[3]Cars returned with single arcs. The purpose of doing that would be to facilitate scaling the model easily to handle cities with many more rental locations. Instead of doing the above, it is possible to use this model as is to incorporate more rental locations. But, adding more arcs in and out of n[3] will make those two parts of the diagram cluttered and opaque. This does not affect the functionality of the model. It only affects clarity of the network representation with the potential for introducing human error from the confusion of dealing with some objects obscuring others.
Downloads of all examples are available in Chapter 1 of the Hands-on Tutorial. However, you can also view all of the examples and their results online without downloading anything. If you wish to change inputs and execute these models on your PC, or modify them in someway, you will have to NETrans them and create their EXEcutables. To do that you will need to download and install ORMSware and its support components, all of which are available for free trial. Instructions for all of that are available at the above link as well.
|
|
Click to go to summaries of all examples and paths to Primer and Hands-on Tutorial |