ORMSwareTM is a proprietary quantitative modeling and programming system developed by Reginald Joules at Ushar Enterprises Inc, Littleton, Colorado, USA
A dedicated truck services company wants a descriptive (what-if) model for sizing a dedicated fleet for a customer based on recurring weekly delivery requirements. The focus during initial phase of the analysis is investment and operational cost consequences of any given fleet size. The what-if model is to be used as a response object to NMOD's Optimization Module to find fleet size with the lowest total costs.
The problem is modeled here as a closed system with fixed resources and deterministic, totally predictable, recurring weekly demands for the resources, since the fleet will be dedicated to a customer. The resources are fleet trucks and demands are truckloads to be shipped to various destinations. The loads transition fleet trucks from available or idle status to busy status for a certain period of time before returning them to available status.
When a fleet truck is assigned to deliver a load, it becomes unavailable to satisfy other demands for a certain period of time. The length of time that truck will be unavailable depends on how long it has to travel to deliver a load and return to base.
In this example, we have classified demands by route durations/route zones. Zones were determined in terms of route durations of one, two, and three days. It will be obvious to the reader that this model can be scaled to refine and extend zone classifications to a minimum of any fraction of a day to a maximum of any multiple of the minimum duration.
From recurring weekly shipping demands projected by the customer, demands for each day of the week were grouped in terms of the number of days they cause a truck to be unavailable (i.e. in terms of route duration/route zones), as shown in the image of the Excel table above.
On any given day when available fleet trucks are insufficient to handle all of that day's demands, excess demands are outsourced; if there is insufficient demand to assign all available fleet trucks, the unassigned trucks go into idle state till the next time period, which is the next day in this formulation.
Formulation of this problem is more easily understood through its ORMSware network diagram towards the top and its supplemental data files. Click the links below to open these files in separate windows for reference while reading the rest of this document.
Following section describes the model:
The model starts execution at the green Start node, viz. nInitializations. The node happens to be [Visio-assigned] object number 1 in this case, indicated as  in the line above the node name. Analysts typically model the middle parts of a model first before dealing with the Start node, so Start nodes often have object numbers other than 1.
The Start node in the top level network of a model is typically used to set up and initialize various variables, perform various non-repetitive tasks, and to launch repeated executions of various cycles (loops) in the model.
There are three cycles in this model as explained below:
nAssignTrucks: This node fetches demands for each route zone from the Excel table shown earlier in this document, calculates available fleet trucks and determines what loads, if any, should be outsourced. It then creates a temporal connection to a and sends to it different signal entities (calculation threads) carrying fleet truck dispatches to all route zones. Notice in the image of the dialog box below for a that its Branch property is set to No/False. This logical blockage is necessary to ensure that traversal along a is restricted to signals sent from n through the temporal connection. The loads assignment algorithm in n determines how many fleet trucks are dispatched to each route zone. Each signal has properties that carry its assigned route zone and associated number of trucks assigned to the zone.
nInitializations: When the model starts running, all trucks in the fleet are in idle state. This node starts the flow of trucks. nAssignTrucks has AND arcs leading into it, which means that it is a Convergence node requiring arrival of a certain number of entities along those AND arcs before it can be evoked. n needs to supply those entities at the start so that fleet flow can begin.
n has a trigger arc  going nDayTracker. An entity launched in this direction will reach n along AND arc . To trigger  for the first time, we need 4 more entities to arrive at that node along AND arcs. To accomplish this we first send a signal to a from the SignalTarget property of n.
OutsourcingCalcs: This node will be triggered only during the statistics and cost calculation period defined by the analyst. We have defined it to be days 8 through 14. This node tracks how many runs to each zone are outsourced and consequential cost of outsourcing per week.
FleetCalcs: This node will be triggered only during the statistics and cost calculation period defined by the analyst. We have defined it to be days 8 through 14. This node tracks how many runs to each zone are made each week by fleet trucks.
FinalCalcs: This node wraps up results reporting on the final day of the analysis horizon, writing to the Results file certain interesting summary information captured during a model run and all of the calculated costs information.
Fibonacci search procedure in NMOD's Optimization Module was used to find optimal fleet size. Fibonacci search is a procedure for finding optimal value of an integer decision variable (in this case, the number of trucks in the fleet) which produces a unimodal response curve over a decision range. In other words, it was obvious in this case that the total cost curve would go down for a while as the fleet size increases from zero and then at some point would start to go up for larger fleet sizes. Thus, the fleet size that yields the lowest total cost value would be the ideal fleet size.
Using Fibonacci search in a model involves inserting two lines of code in the model, one for providing a stimulus for probing the model and the other for sending the model's response to the optimizer. These lines can remain in the model even if the analyst wants to do just one what-if probe at a time.
The stimulus line should go where the model sets the decision variable's value. In the case of this model, it is in nInitializations (CALL OptimizationStimulus). This call updates the value of FleetSize with the stimulus value provided by the optimizer. If the model is being run in the what-if probe mode instead, this call will leave FleetSize unaffected.
The response line goes where total costs are computed at the bottom of the Trans property of nFinalCalcs (CALL OptimizationResponse).
There are, of course, less naive approaches than the trivial search described above. One approach would be to stop the search immediately, as it proceeds from one end of the solution range to another, when total costs start going up. This too can be cumbersome and inconsistent for large scale models in large ranges. For example, if the range we guessed is 65 to 200, we would have gotten lucky and found the answer in 3 probes. But, if we guessed 0 to 135 instead (same width of range), it would have taken 68 probes to find the optimum.
Click to go to summaries of all examples