Dallas Petroleum

Introduction and Background

Dallas Petroleum, started over one hundred years ago, owns seven refineries in
Oregon, California, Texas, Louisiana, and Indiana. The refinery in question is called
“Shreveport” refinery, which is divided into three maintenance zones as shown below:

Manager

Zone 1 Zone 2 Zone 3

Etc.
Area Area Area Area
Foreman Foreman Foreman Foreman

The goal of this project is to create a better equalization of the workloads. Since the
boundaries could not be changed, for a series of reasons, it was decided to assign each
unit (from one to 54), to three different “zones”. A detailed chart was created, listing
every unit, its distance from headquarters, hours of maintenance required per week, and
possible emergency procedure estimations. Please see the attached Zones.txt,
Hours.txt., and Emergency.txt files for further information. A programming language
called MPL was consulted, after forming an LP, to determine the optimal solution for this
problem. This project aims to explain these results.

Constraints and Further Information

There are several more facts that need to be known before attempting this
problem, in addition to the table provided. There are three different laborers who are
hired on the plant: plumbers, electricians, and mechanics. Their hourly salaries, in
addition to the maximum of time each may spend during emergency operations, are listed
in the table below:
 Hourly Salary ($) Emergency (%)
Plumber 10 8
Electrician 12 10
Mechanic 8 6

Furthermore, it is estimated that for every additional 100 feet each worker must travel to
reach his or her maintenance destination, it take approximately 0.1 hours from their
working time. These figures help establish a solid basis for formulating an LP for this
problem.

Formulating an LP

The LP will be divided as follows:

• Title
o Optimal Maintenance Boundaries
• Index
o unitsnumber: labeled 1-54
o worker: plumber, electrician, mechanic
o zone: zone 1, zone 2, and zone 3 (z1-z3)
• Data
o Rate: hourly salaries of employees
o EmergencyWorkerMax: maximum percentages of time allowed to work
on emergency operations
o EmergencyPercent: estimated time (in % of total labor time) spent on
emergency work
o Distance: distance to each unit
o WorkerHours: hours of work required, by each of the three workers, at
each unit
o MaxUnitNumber: 54, the total number of units
• Variables
o We are attempting to find optimal zones for each unit (location), so this
will be named Location
• Macros
o TotalRate: total salary paid NOT accounting for distance
o TotalDistanceAddition: additional salary, accounting for 0.1 hours per 100
feet in labor costs due to traveling
• Model
o Our goal is to minimize cost, by assigning the nearest units to each
individual zone: MIN Cost = TotalRate + TotalDistanceAddition
• Subject To/Constraints
o The same amount of hours of labor required at each unit must remain the
same
o The workers may not exceed the percentage of emergency work
Following this, it is simple to enter this into a software program called MPL, which will
compile all of this information and find optimal solutions for the problem, as well as the
minimum cost/expenditure required.

Using MPL to Find an Optimal Solution

Given the above conditions, what follows is the code entered into the program:

TITLE
Optimal_Maintenance_Boundaries;

INDEX
unitnumber := (U1, U2, U3, U4, U5, U6, U7, U8, U9, U10, U11, U12, U13, U14,
U15, U16, U17, U18, U19, U20, U21, U22, U23, U24,
U25, U26, U27, U28, U29, U30, U31, U32, U33, U34,
U35, U36, U37, U38, U39, U40, U41, U42, U43, U44,
U45, U46, U47, U48, U49, U50, U51, U52, U53, U54);
worker := (plumber, electrician, mechanic);
zone := (Z1, Z2, Z3);

DATA
Rate[worker] := (10.00, 12.00, 8.00);
EmergencyWorkerMax[worker] := (0.08, 0.10, 0.06);
EmergencyPercent[unitnumber] := DATAFILE("Emergency.txt");
Distance[unitnumber, zone] := DATAFILE("Zones.txt");
WorkerHours[unitnumber, worker] := DATAFILE("Hours.txt");
MaxUnitNumber := 54;

VARIABLES
Location[unitnumber, zone] -> Loc;

MACROS
TotalRate := SUM(worker, unitnumber: Rate * WorkerHours);
TotalDistanceAddition := SUM(zone, worker, unitnumber: Location * 0.001 *
Distance * WorkerHours);

MODEL
MIN Cost = TotalRate + TotalDistanceAddition;

SUBJECT TO
WorkMinimum[unitnumber, zone] -> WM:
SUM(zone: Location) = MaxUnitNumber;

EmergencyHours[unitnumber, zone] -> EH:

 SUM(unitnumber, worker: WorkerHours * EmergencyPercent) <= SUM(unitnumber,
worker: WorkerHours * EmergencyWorkerMax);

END

Here, each bolded section represents the different phases described above.

Explanation of Results

After compiling and running the program, the results gave us optimal solutions
for solving this problem. In other words, we are now able to allocate different zones
(zone 1, zone 2, or zone 3) for workers to work on each of the 54 different units
comprising the plant. Also, one can see the minimum cost necessary to effectively run
the plant as anticipated- given all the constraints and facts in the problem, this is the best
solution which would yield the smallest amount of expenditures, hence ultimately
minimizing loss.

SOLUTION RESULT

Optimal solution:

MIN Cost = 22318.2761

MACROS

Macro Name Values

-----------------------------------------------
TotalRate 21122.0000
TotalDistanceAddition 1196.2761

As one can see here, the minimum cost is $22,318.28. It is also interesting to note that
the TotalRate and TotalDistanceAddition add up to this amount, although it should come
as no surprise as those are the ones we are solving for.

Further Solutions

We were also given information regarding each individual unit, and what zone
would be best allocated for each one. The complete printout is included at the end of this
report, but for current analysis, a small portion of it is provided below:

DECISION VARIABLES
VARIABLE Location[unitnumber,zone] :

unitnumber zone Activity Reduced Cost

------------------------------------------------------
U1 Z1 0.0000 0.3687
U1 Z2 54.0000 0.0000
U1 Z3 0.0000 0.2864
U2 Z1 0.0000 0.3012
U2 Z2 54.0000 0.0000
U2 Z3 0.0000 0.1031
U3 Z1 0.0000 0.3137
U3 Z2 0.0000 0.2681
U3 Z3 54.0000 0.0000

Here, one can clearly see what zone should be chosen for each individual unit. For Unit
1, for example, Zone 2 requires the least amount of cost. For Unit 2, Zone 2 is also best
suited. For Unit 3, however, it appears that Zone 3 would be better at minimizing cost.
Going through these solutions, one can then allocate each individual unit with a suitable
zone, so that the workers have to commute as little as possible. This drastically reduces
the amount of money spent on idle time traveling, putting the company at less of a loss.
What follows is a more in-depth explanation of these results, as well as a description of
how Operations Research and optimization using powerful computer software helped
achieve these results.

Further Analysis of Results

In an ideal situation, every unit would be grouped together in three dense groups,
named zones, and headquarters would be exactly in the center providing minimal
distance to travel. This is not, and can realistically not, be the case. Therefore, the results
from this project provide the best alternative given the location constraints.

Upon further investigation, the shadow prices of the results are examined.
Although the entire results are provided separately with this project, again we will look at
the first four units and the significance of the shadow price listed next to each one:

UNIT ZONE SLACK SHADOW PRICE

U1 Z1 0.0000 0.1585
U1 Z2 0.0000 0.0000
U1 Z3 0.0000 0.0000
U2 Z1 0.0000 0.2136
U2 Z2 0.0000 0.0000
U2 Z3 0.0000 0.0000
U3 Z1 0.0000 0.1594
U3 Z2 0.0000 0.0000
U3 Z3 0.0000 0.0000
 U4 Z1 0.0000 0.1654
U4 Z2 0.0000 0.0000
U4 Z3 0.0000 0.0000

A shadow price is essentially the change in the final value of the optimal solution,
when we “relax” or “modify” constraints by one unit. This is not to say, for example,
that one can assume the plant is torn down and rebuilt completely! Rather, the values of
shadow prices give us insight into the problem. These prices tell us how much we would
need to pay for a different zone/distance. We should not have to pay any more than that.
So, for example, for Unit One, the price for zone one would increase by a factor of
0.1585. Similarly, for Unit Two, it would increase by a factor of 0.2136, and so forth.

Finally, the introduction of the solution tells us more specific information about
the project itself. This can be very useful when compiling and analyzing data from
several different projects, and distinguishing between them:

MODEL STATISTICS

Problem name: Optimal_Maintenance_Boundaries

Filename: OR441Project.mpl
Date: December 9, 2008
Time: 15:19
Parsing time: 0.09 sec

Solver name: CPLEX (11.1.1)

Objective value: 22318.2760940
Iterations: 0
Solution time: 0.30 sec
Result code: 1

Constraints: 162
Variables: 162
Nonzeros: 486
Density: 1.9 %

As one can see, the problem name, as well as the filename, is displayed. In
addition to this, various other information like the date and time it was run, name of the
specific solver (software) that solved the problem, as well as the time it took to solve.
Here, a solution time of 0.30 sec is very small! However, when dealing with much
bigger problems and thousands of variables, this number is likely to increase as it will
take the computer more time to process the information. Furthermore, we are given how
many constraints, variables, and nonzeros were processed, as well as density- measured
in percent.
Conclusion

Looking at the results of this project, it is clear that things could be done
differently. Although Dallas Petroleum has been very successful in its acquisitions and
policies, this particular plant could be further optimized. Operations Research helped
look into the problems and constraints faced, and provided us with the groundwork to set
up a problem to solve it. Since such work can be very difficult to execute by hand, there
are several software programs available to assist people in doing the basic computations.
In all, this follows very closely what was learned in Operations Research 441, but went
much more in-depth and used figures that hardly could be manipulated without the aid of
a computer.