ORMSware^{TM} is a proprietary
quantitative modeling
and programming system developed by US Army veteran Reginald Joules at Ushar Enterprises Inc, Littleton, Colorado, USA,
with keen interest in national defense problems

ORMSware modeling examples posted here are simplified versions of actual
problems. Proprietary data have been changed where appropriate. If you plan to follow these
examples closely it will be helpful to reflect
on and map out
first how you would solve these problems using tools with which you are
familiar. Recall, however, that ORMSware is not available for purchase.

A key part of the ORMSware paradigm is the Customer-Surrogates/Probes/Thread-heads concept and the
birth and death process (from Stochastic Processes and Discrete Event Simulation
in Operations Research/Management Science/Decision Science). Modeling as well as
programming are viewed in generalized terms of customers entering and exiting
birth and death process systems. Customers are represented by
surrogates/probes/thread-heads, etc., which travel simultaneously through queuing networks within the
birth and death system. Execution of the program is therefore logically multithreaded.

At times the concept conveyed by "probe" is more communicative than
"surrogate." You will see "probes," "surrogates," "entities" and "thread-heads"
used interchangeably in the briefings here.

Click Problem heading or corresponding image for more
information (diagrams, data, descriptions) on each problem.

This is a model for determining the best sequences of actions for replacing a machine in a production operation.
Two versions of the general problem are presented. The first one is a trivial
version involving just a few decision options over a planning horizon. It is
solved using a trivial, mindless, explicit and exhaustive evaluation of all
possible action sequences. The second one is a non-naive prescriptive if-what
(or reverse what-if) approach.

Naive Version: This is the version you'll see by clicking the Problem
1 subheading above. Decision choices in this version involve buying a new or older model of the machine
with options of keeping it or replacing it any given plan year with another new or older model,
repeating this decision process over a desired planning horizon. Older models have lower
purchase costs, but higher maintenance costs and lower trade-in values.

This version shows how easily alternative solution
threads can be recorded and retrieved in NMOD. The reader will also see how the model can
be easily expanded to accommodate more equipment age choices, price changes of
new equipment over time, present value of alternatives, changeover costs, etc.
Best sequences of actions over the time horizon are then calculated and sorted by exhaustive,
explicit evaluation of all possible action sequences.

Non-Naive Version - dynamic programming implementation using ORMSware discrete event
simulation: This version (being posted 8/27/2016) is more interesting. It
is truly in the ORMSware spirit, using its discrete event simulation paradigm
to handle the "curse of dimensionality" issue. It is described in a series of videos posted
below.

Please reload the page and go to the video of interest to you if the video
resolution turns bad or video transmission gets stuck. We are, unfortunately,
unable to control this problem.

Some of the concepts used in this example:

Automatic expansion of NMOD environment to accommodate the growing size of
a problem

Use of Microsoft Excel tables in NMOD models

OR arcs (cause target nodes to fire as soon as flows along these arcs
reach the nodes)

Transformation of surrogate/probe/execution thread-head properties as they traverse model's
network

Use of Duration property of network objects and Event queue to order
alternatives by cost

Trivial short path method to rank alternative solution paths

TravelNotes procedure to record decision-consequence path of each solution
alternative

ShowTravelNotes procedure to retrieve decision-consequence path of each
solution alternative

Extending a network object's content beyond what can be entered through
Visio interface

Declaring model level analyst-defined variables

Start node

Normal node

Network node

Role property of network objects (grayed nodes and arcs with dashed lines
are Support objects)

Use of Dummy/Support nodes and arcs (allows clarification of flows and
precedences)

This is a descriptive model for determining fleet migration of
a rent-a-car operation, given the probability of where a customer is likely to
drop off a vehicle picked up at one of its outlets.

The reader will be able to see how this simple model can be
easily extended to formulate pricing strategies, perform tradeoff analyses to determine
charges and discounts for improving competitiveness and profitability, develop cost-effective
operational plans, etc.

Some of the concepts introduced in this example:

Parallel/multiple arcs between any given pair of nodes

AND arcs and AND arc multipliers

Changing AND arc multipliers programmatically

Convergence node (node with at least one AND arc terminating in it)

Incorporating analyst-defined variables and procedures at model level

Working with analyst-defined vectors/matrices/arrays

This is a quick-and-dirty deterministic model for sizing daily
tax returns processing capacities of IRS Regional Centers. The objective of the
model was to make a contract bid competitive by minimizing investment costs
while meeting all required performance specs.

The reader will be able to see how the model can be extended
to accommodate the probabilistic nature of of tax returns arrival rates and
service (returns processing) rates, network architecture and performance for
supporting returns processing, workload balancing among the centers, etc., all
with the objective of reducing costs while meeting performance specs.

Some of the concepts introduced in this example:

Using NMOD's Optimization Module

Goal-seeking

Temporal arc -- a connection that comes into existence temporarily to
connect a node or arc to another node or arc. Temporal arc disappears once the
connection is complete.

Problem 4: Order Processing Operations

NOTE: Details of this problem have been
taken offline as the concepts covered are now present in updated versions of
other examples available at this site.

This is a simplified, truncated version of a back-office
operations tool which a small business uses to transform orders received over
the Internet to packages to be shipped.

This example also demonstrates NMOD's hierarchical modeling
capabilities. The reader will be able to see how the tool can be expanded to
connect the business's order processing operations to financial performance
analysis, inventory management, etc.

Some of the concepts introduced in this example:

Network node

Subnets to create hierarchical networks

Mixing physical process and logical process objects in networks

Recursive network referencing

NMOD's table lookup function

Return node

Arrival node

Departure node

One of the ways NMOD compresses modeling process cycle time

This is a descriptive model for calculating total costs driven by fleet size
of a dedicated trucking services
operation.

We show how this descriptive (what-if) model
is turned into a prescriptive (optimization/if-what) model for finding minimum
cost fleet size by having the model respond to Fibonacci search stimuli from
NMOD's Optimization Module.

The reader will also be able to see how the simple model presented
here can be expanded to include maintenance operations, driver availability,
etc. to improve financial and operational performance of a truck fleet dedicated
to a customer; and, still, in spite of the increased complexity of the what-if
model, be able to use the same Fibonacci search with no additional effort to
find optimum fleet size.

Some of the concepts introduced in this example:

Optimization of an integer control/decision/... variable using Fibonacci
search

Using Trivial Search to demonstrate to stakeholders validity of Fibonacci
search results

Temporal arcs with Duration greater than zero

User-defined data structures/derived types

Tracking extrema of performance variables and values of related variables

A retail chain in UK with 772 stores and 9 distribution centers (DCs) wanted
a system for computing minimum-cost distribution of roughly 13 million cases of
goods every week. Rather than exploring all [772 * 9 = 6948] links the company wanted the program to
pick only 3 closest DCs to supply each store, limiting DCs-to-stores
supply links to just 2316.

We first show you an algorithm attempted by an IT consultant bidding on the
project (by explicitly and exhaustively evaluating all feasible allocations to
pick the best distribution plan). Most people are likely to try such an approach, only to discover that
there will not be enough time in their lifetime to get an answer to the problem.

We then we go on to show an Operations Research/Management Science (dynamic
programming) formulation of the problem and the ease with which the solution was
implementedwith ORMSware. It produces a quick-and-dirty Initial Plan in
a split-second and
the Final Plan in a few seconds on a Windows 7 HP 2400 MHz notebook computer.

Some of the concepts introduced in this example:

More examples of creating and using derived types (data structures)

Using queues to sort items and hold entities (Store and Retrieve)

Procedures and functions available for getting status information about
queues

More use signals and signal targets (temporal arcs/connections)

Using Events Queue to sequence entities according to cost factors

Operations management problems such as machine scheduling, vehicle routing,
crew scheduling, tool path design, and numerous others, involve the issue
of knowing how to systematically find all possible ways any given set of items or activities can be
ordered/arranged/sequenced, even if all sequences may not be explicitly and
exhaustively explored.

The focus of this example is not the sequences (permutations) generating algorithm developed
with ORMSware or its expansion to solve an asymmetric traveling salesman problem
(ATSP). Rather, the focus is the general process of getting to the final
formulation of a model using typical ORMSware thinking.

If you are not familiar with existing permutation algorithms, we have provided a
link to show you a programming language implementation of a permutations
algorithm for comparison with the ORMSware solution.

Some of the concepts covered in this example:

BeenAt functions and procedures that initialize, track and set node
visitation histories of surrogates

Notation for, and working with, array sections (e.g. vector out of a
table/matrix)

Reading tables from Excel, which have non-default lower limits for rows
and columns

Echo statement ({?|variable}) for tracking and collecting
values of a given property or variable

Note: After demonstrating the ORMSware thinking process, Permutations model
is extended to solve asymmetric TSPs with complex cost/performance functions.
The quick-and-dirty algorithm can be refined to reduce
computational loads for solving larger problems.

Click Problem 7 link above to review Sequencing and Traveling Salesman Problem.

Downloads

EXE downloads of all examples are available by contacting us at 972-752-7152.