Вы находитесь на странице: 1из 42

Multi-Attribute Facility Layout and Design:

A Graphic User Interface (GUI) for MAFLAD

- Project Report -

Patrick Simon
University of Massachusetts Amherst
April 25th, 2005

1 Introduction 5

2 Problem Statement 5
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 The Facility Layout Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Models for the Facility Layout Problem . . . . . . . . . . . . . . . 6
2.2.2 The Quadratic Assignment Problem . . . . . . . . . . . . . . . . . 7
2.2.3 The Quadratic Set Packing Problem . . . . . . . . . . . . . . . . 8
2.2.4 A Relaxed Assignment Formulation of the QSP . . . . . . . . . . 9
2.3 Solution Procedures for the Facility Layout Problem . . . . . . . . . . . . 11
2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Optimal Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 Suboptimal Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4 MAFLAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Project Proposal 16
3.1 Purpose and Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Current Version of MAFLAD . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Programming Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Program Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Project Results 18
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Proposal versus Implementation . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Compliance with Proposal . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2 Non-Compliance with Proposal . . . . . . . . . . . . . . . . . . . 19
4.3 Program Features and Functionality: Users Manual . . . . . . . . . . . . 19
4.3.1 Installing G-MAFLAD . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.2 Starting G-MAFLAD . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.3 The Main Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3.4 Opening and Closing an Input File . . . . . . . . . . . . . . . . . 22
4.3.5 Running an Input File and Receiving Output . . . . . . . . . . . 23
4.3.6 Printing and Saving the Output . . . . . . . . . . . . . . . . . . . 27
4.3.7 Editing an Existing and Creating a New Input File . . . . . . . . 28
4.4 Programming Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Conclusion 37
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Project Critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A G-MAFLAD Compact Disc 42

List of Figures
1 Introductory Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 The Main Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Opening an Input File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Selecting the Limited Lookahead Heuristic . . . . . . . . . . . . . . . . . 24
5 Limiting the Solution Time . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Numeric and Graphic Output for Bazz1.dat . . . . . . . . . . . . . . . . 26
7 Numeric and Graphic Output for Bazz3.dat . . . . . . . . . . . . . . . . 26
8 GIF-File of Graphic Solution Output for Bazz1.dat . . . . . . . . . . . . 28
9 Excerpt from Bazz1.dat (Elliptic) . . . . . . . . . . . . . . . . . . . . . . 29
10 Interface for Editing the Bazz1.dat Input File . . . . . . . . . . . . . . . 31
11 Interface After Activity 1 of Bazz1.dat Has Been Selected . . . . . . . . . 32
12 Interface after Alternate was Added . . . . . . . . . . . . . . . . . . . . . 33
13 Changing the Placement Utility Values . . . . . . . . . . . . . . . . . . . 34
14 Editing the Flow Matrix for Bazz1.dat . . . . . . . . . . . . . . . . . . . 35
15 Creating a New Input File . . . . . . . . . . . . . . . . . . . . . . . . . . 36

1 Introduction
Multi-Attribute Facility Layout and Design (MAFLAD) is a computer program that
was introduced by Smith and Macleod [20] in 1988. MAFLAD solves the problem of
physically organizing a number of entities within a given facility to optimality by means
of an underlying branch and bound algorithm. The approach chosen with MAFLAD is
based on the Quadratic Set Packing (QSP) model, which offers various computational
advantages over the more general Quadratic Assignment Problem (QAP) (Delvecchio-
Smith [4]), which was first introduced by Koopmans and Beckmann [10] in 1957 to model
the assignment of indivisible resources to a given set of locations.

The purpose and goal of this project was to extend the original version of MAFLAD by
programming a user interface that facilitates the users interaction and communication
with MAFLAD. Among other features, the interface presents a graphic output of the
solution layouts generated by MAFLAD. In addition, the user can edit and tweak the
input data if the current solution set indicates opportunity for improvement through
changes of the input data.

The remainder of this proposal is organized as follows: In the second chapter, a liter-
ature review on the underlying Quadratic Assignment Problem (QAP) and Quadratic
Set Packing Problem (QSP), respectively, is presented along with a survey of optimal
and suboptimal solution procedures for the facility layout problem. In addition, the
approach chosen by Smith and MacLeod [20] to solve the facility layout problem is ex-
plained in greater detail. The third section is concerned with the specification of the
actual project proposal. The requirements, scope and goal of the project are defined.
Properties and potential difficulties of MAFLAD are discussed and - whenever possible
- improvement proposals are made. The projects result are included in section 4 of this
report, which concludes with some final remarks in section 5.

2 Problem Statement
2.1 Introduction
The facility layout problem is well-known within the field of combinatorial optimiza-
tion (e.g. Francis and White [6]). The general problem is concerned with finding an
optimal arrangement of a given set of n activities or departments within a system such
that the total cost associated with the material flow between the activities is minimized
(Kusiak and Heragu [11]). Various applications are of importance to layout optimization,
including, but not limited to communication networks, fixed facility configurations, and
material flow networks. Throughout the past 50 years numerous contributions have been

made to the literature of layout optimization. This section intends to provide a concise
overview of models used for the facility layout problem and the associated procedures
of exact or heuristic nature developed to solve the facility layout problem. Further-
more, the specific approach of MAFLAD and its underlying assumptions are portrayed.
Finally, the problem statement of this proposal is presented in section 2.4.

2.2 The Facility Layout Problem

2.2.1 Models for the Facility Layout Problem
According to Kusiak and Heragu [11] there are five categories of models which are
used to analyze facility layout problem:
Quadratic Assignment Problem (QAP)
Quadratic Set Packing Problem (QSP)
Linear Integer Programming (LIP)
Mixed Integer Programming (MIP)
Graph Theoretic Models (GTM)
Since MAFLAD is mainly concerned with the QAP and the QSP, respectively, this survey
only briefly comments upon the remaining three modelling approaches. Evidently, all
approaches emanate from the original QAP-formulation.

Lawler [12] was the first one to model the facility layout problem as a linear integer
programming model by making a number of changes to the initial QAP-formulation.
Lawlers approach, however, did not facilitate the solution process, but increased its
computational complexity by adding a large number of constraints. In a survey on the
facility layout problem published by Meller and Gau [13] in 1996, the linear programming
approach was no longer included in the discussion of promising solution procedures.

According to Kusiak and Heragu [11], the mixed integer programming approach devel-
oped by Kaufman and Broeckx [8] has the smallest number of variables and constraints
of all integer programming formulations of the QAP. The approach was later successfully
used as part of a goal program to assign offices in buildings.

The graph-theoretic formulation of the QAP assumes that the critical pairs of activities
which are to be located next to each other are known. The area and shape of the
departments are ignored and each department is represented by a node in a planar graph
(Meller and Gau [13]). The objective is then to construct a graph which maximizes the
sum of the weights on the arcs between all activity pairs.

In the past years, substantial effort was devoted to changing the original formulation
of the QAP to allow for efficient optimization (e.g. Kettani and Oral [9]). One of the
most promising approaches lies in the Quadratic Set Packing formulation of the QAP.
The QAP and QSP are both portrayed in the following paragraphs.

2.2.2 The Quadratic Assignment Problem

As pointed out earlier, the Quadratic Assignment Problem was first introduced by
Koopmans and Beckmann [10] in 1957 to model the assignment of economic activities
to a set of locations. In 1963, further contributions to the QAP were made by Lawler
[12]. Koopmans and Beckmann found earlier linear programming approaches to be rather
inadequate since they assumed that the benefit from an economic activity at a specific
location was independent of the uses of other locations. In the QAP, each department is
assigned to a specific location. The cost of placing a department at a particular location
depends on the location of the interacting departments (Meller and Gau [13]). This
inevitably leads to a quadratic objective function, to which the problem owes its name.
The QAP is a very difficult problem, which was proven to be NP-complete by Sahni
and Gonzalez [18]. The difficulty in finding optimal solutions to the QAP can mainly
be attributed to two factors (Bazaraa and Sherali [2]):
(I) The presence of a large number of 0-1 variables which makes the use of explicit
enumeration methods almost impossible,
(II) The need to optimize a quadratic function expressed in 0-1 variables, which
makes the use of calculus completely inappropriate, unless it is equivalently refor-
mulated as a continuous nonlinear programming problem.
The QAP can be formulated as follows (e.g. Pardalos and Wolkowicz [16]):
n X
X n X
n X
n n X
X n
M inimize fij dkl xik xjl + cik xik
i=1 j=1 k=1 l=1 i=1 k=1

subject to
xik = 1 i = 1, ..., n (1)
xik = 1 k = 1, ..., n (2)
xik {0; 1} i = 1, ..., n, and k = 1, ..., n (3)
fij = flow of material between activity i and j
dkl = distance between locations k and l

The objective of the QAP is to find an assignment of all facilities to all locations, such
that the total cost of the layout is minimized. The first term in the objective function
minimizes the flow cost between all pairs of activities while the second term minimizes
the fixed site costs for activity i at site k. The first set of constraints (1) ensures that
exactly one activity is assigned to each location, while the second set of constraints (2)
ensures that each activity is assigned to exactly one location. This way, not more than
one activity is assigned to a specific location, nor is there any activity that remains
unassigned. The binary decision variables xik and xjl equal 1 if activity i is located at k
(j located at l ), and equal 0 if otherwise. The quadratic nature of the QAPs objective
function immediately becomes apparent by examining the interdependency of activity
allocations in the above formulation.

Various solution procedures for the QAP are based on the branch and bound ap-
proaches that were first introduced by Gilmore [7] and Lawler [12]. The approach cho-
sen by Smith and Macleod [20] is based on a variation of the QSP, the Quadratic Set
Packing Problem. Its structure and properties are described in the following section.

2.2.3 The Quadratic Set Packing Problem

The Quadratic Set Packing Problem (QSP) is a model which can be used to represent
various problems related to optimal facility layout. In this context, it was first intro-
duced by Bazarra [1] in 1975. As stated earlier, the QSP assumes that the system of
interest has the form of a grid layout, where clusters of grid cells associated with the
different activity locations are known in advance. This way, different shapes and sizes
of activities can be taken into account as long as they can be described by a set of cells
within the grid layout. Because of the QSPs importance for the approach chosen by
Smith and Macleod [20] it is included in this section. In the following formulation of the
QSP, which is taken from Bazaraa [1], the total area required to arrange all activities is
divided into q blocks.
The QSP is to:

X Ii
n X Ii X
n X
X Ik
n X
M inimize aij xij + fik dji ,lk xij xkl
i=1 j=1 i=1 j=1 k=1 l=1

subject to
xij = 1 i = 1, ..., n (4)
n X
pijt xij 1 t = 1, ..., q (5)
i=1 j=1
xij {0, 1} i = 1, ..., n and j = 1, ..., Ii (6)

q number of blocks into which the total area occupied by all facilities is divided into
Ii number of potential locations for facility i
Ji (j) set of blocks occupied by facility i if it is assigned to location j
d(ji , lk ) distance between the centroids of locations j and l if facility i is assigned to
location j and facility k is assigned to location l
xij equals 1 if facility i is assigned to location j and 0 otherwise
pijt equals 1 if block t  Ji (j) and 0 otherwise

The first set of constraints ensures that each activity is assigned to exactly one possible
cluster within the grid layout. The second set of constraints ensures that a cell is not a
member of more than one cluster of a given activity, i.e. a cell is not assigned to more
than one activity. The rectilinear metric is applied to measure the distance between the
centroids of two activity clusters k and j. Meller and Gau [13] also refer to the Euclidean
metric as a measurement of distance, either from the centroids or input/output points
of two given clusters, with the later option being more accurate depending on the layout
set-up. Kusiak and Heragu [11] point out that although the above formulation can be
used to represent a general facility layout problem, a major disadvantage lies in the sharp
increase in the problem size as the total area is divided into smaller blocks. The original
QSP formulation thus offered little computational advantage over the QAP formulation
of the facility layout problem. In order to overcome this issue, Smith and MacLeod [20]
developed a relaxed assignment formulation of the QSP, which is described in the next

2.2.4 A Relaxed Assignment Formulation of the QSP

Smith and MacLeod [20] offer a relaxed model of the QSP based on the following
formulation presented by Smith and Pelosi [21] in 1984:
M aximize Z= ukt xkt + ukj ( xkm xjn )
k t k j mnA

subject to
ikt xkt 1 i = 1, ..., I cells (7)
k t
xkt = 1 k = 1, ..., K activities (8)
xkt {0;1} k = 1, ...K and t = 1, ..., T (9)

xkt denotes the tth cluster of cells to which the k th activity can be assigned, i.e.:
xkt is 1 if the kth activity is assigned to the cluster of cells designated by t and xkt is 0
if otherwise.
ikt is 1 if cell i is a member of the tth cluster for activity k, and 0 otherwise.
Akj is a set of planar arcs indicating critical relationships between activity pairs xk and
xj for each alternative (xkm , xjn) ;
dmn is the rectilinear distance between cluster m for activity k and cluster n for activity
ukt is an expected utility-of-place coefficient for the tth cluster of activity xk ;
ukj is an expected utility of flows coefficient between activities xk and xj

The index t in the binary decision variables of the linear term of the objective function,
i.e. xkt and ukt , indicates the tth alternate cluster for activity k and its associated
utility value within the grid layout. In the above formulation, activities are assigned to
the layout as feasible combinations of cells within the grid (Smith and MacLeod [20]).
Although this formulation of the QSP resembles the formulation presented in section
2.3, it differs in many ways. In contrast to other formulations, this approach does not
only incorporate factors such as distance or time travel into the objective function, but
a number of additional quantitative or qualitative factors important to facility layout.
Such factors can be divided into 6 categories (Smith and MacLeod [20]):

Physical Factors

Human Comfort Factors

Economic Factors

Safety/Security Considerations

Flexibility Factors

Regulatory Compliance Factors

Evidently, any of these factors might just be as important as minimizing total distance
or time required for material handling within a given facility. Based on this observation,
utility coefficients associated with the placement of an activity and the flow between
two activities were incorporated into the linear and nonlinear terms of the objective
function. The rationale behind this approach is to restrict the attributes incorporated
into the model to those which can be measured on a distance scale. This facilitates the
construction process of the associated utility function.

Nevertheless, the solution to this QSP formulation is still very difficult, which led
Smith and Pelosi [21] to develop the following lagrangian relaxation of the initial model,
which incorporates the difficult activity assignment constraints into the objective func-
M aximize ukt xkt + ukj ( xkm xjn ) i ( ikt xkt 1)
k t k j mnA
dmn i k t

subject to

xkt = 1 k = 1, ..., K (10)
xkt {0, 1} k = 1, ..., K and t = 1, ..., T (11)

Smith and Pelosi [21] made a crucial observation that finally led to the Relaxed Assign-
ment Problem (RAP). In order to achieve feasibility in the assignments of the activities
one had to take advantage of the overlapping of activity alternatives, i.e. some cluster
alternatives certainly contained the same cells. Activity pair terms, which overlapped
could thus be erased from the nonlinear terms. The entire third term of the objec-
tive function could simply be dropped asP a result.
P P The RAP thus is identical with the
above relaxed assignment model save the i i ( k t ikt xkt 1) term, which is simply
dropped from the objective function. In conclusion, Smith and Pelosi [21] had come up
with a much simpler formulation of the assignment problem, which lent itself to the
application of a Branch and Bound algorithm, which is described in the next section.

2.3 Solution Procedures for the Facility Layout Problem

2.3.1 Introduction
The procedures that have been developed to solve the facility layout problem can be
divided into two categories:

Optimal Algorithms
Suboptimal Algorithms
The first group of algorithms seeks to find an optimal solution for the given facility
layout problem, while the second group applies some form of heuristic, which may or
may not find an optimal solution, but terminates after a certain number of iterations
(e.g. Nemhauser [14], Christofides [3]). In what follows, both approaches are described
in greater detail along with a brief comment on their advantages and disadvantages,
respectively. Finally, the approach taken with MAFLAD is portrayed within the greater
context of algorithms for the facility layout problem.

2.3.2 Optimal Algorithms

According to Kusiak and Heragu [11], two main forms of optimal algorithms have
been of importance to the facility layout problem:
Branch and Bound Algorithms
Branch and Bound algorithms solve a given problem to optimality, if there is a feasible
(and optimal) solution to it. In 1962, Gilmore [7] was the first one to develop a branch
and bound algorithm for the facility layout problem followed by Lawler [12] in 1963.
There were several other contributions made to this field in the past years. Most of the
algorithms are based on stage by stage assignment of facilities to locations. Differences
have occurred in the method of computing upper and lower bounds and in the search
strategy of the branches. Substantial effort was devoted to developing parallel Branch
and Bound algorithms to accelerate the search process (e.g. Roucairol [17] or Edwards
[5]). As stated earlier, MAFLAD is part of the Branch and Bound algorithm family to
solve the facility layout problem.

Due to the minor importance of cutting plane algorithms for this project, only a few
comments are here included. Cutting plane algorithms can be an efficient approach to
solve integer and combinatorial optimization problems. In the case of the facility layout
problem, they have proven to be computationally complex. Kusiak and Heragu [11]
name Bazaraa and Sherali [2] as the main contributors in this field.

According to Meller and Gau [13], for example, optimal algorithms require little time
to find the optimal solution to a given problem, but need substantial computational effort
to verify the optimality of the solution by enumerating a large number of solutions. Due
to this shortcoming, researchers have been focusing on the development of heuristic
Branch and Bound and cutting plane algorithms, which terminate prematurely after a
certain number of iterations.

2.3.3 Suboptimal Algorithms
Suboptimal algorithms for the facility layout problem can be broadly divided into four
categories (Kusiak and Heragu [11]):

Construction Algorithms

Improvement Algorithms

Hybrid Algorithms

Graph Theoretic Algorithms

The intention of applying heuristics to solve the facility layout problem is mainly based
on the disadvantages associated with optimal algorithms, which to date can only solve
instances of the facility layout problem with a maximum of 30 activities and require
substantial computational effort.

Construction algorithms assign facilities to a site one at a time until the layout is
obtained. Improvement algorithms require an initial feasible solution as an input to
the solution process. Feasible facility layouts are often randomly generated and then
improved by the algorithm if possible. Hybrid Algorithms have characteristics of both
- optimal and suboptimal - algorithm classes. A Branch and Bound algorithm, for
example, which terminates prematurely with an initial feasible facility layout could be
combined with an improvement heuristic. There has been substantial effort devoted to
graph-theoretic algorithms to solve the facility layout problem. Meller and Gau [13] also
point out the importance of this approach.

2.3.4 MAFLAD
In what follows, the algorithm behind MAFLAD and some of its properties are de-
scribed. This section is based on work by Smith and Pelosi [21], Smith and MacLeod
[20], Delvecchio-Smith [4], and Smith and Garcia-Diaz [19].

MAFLAD is an optimal seeking branch and bound program which delivers a solution
to the multi-attribute facility layout problem. The underlying algorithm is based on the
QSP formulation as presented in section 2.2.4. The user is required to input the cells
of the alternate activity locations into the program. Currently, MAFLAD offers three
heuristics for the searching and pruning of the solution tree:

Greedy Heuristic

Best Future Value Heuristic

Limited Lookahead Heuristic

The underlying branch and bound algorithm has seven distinct steps:

Step 1.0: Pre-Processing

Step 2.0: Activity Node Set Generation

Step 3.0: Critical Communicating Pairs Generation

Step 4.0: Branching Process

Step 5.0: Bounding Process

Step 6.0: Backtracking

Step 7.0: Solution Output

In what follows, each step is briefly described (for a more detailed description please see
Smith and Garcia-Diaz [19].

Step 1.0 In the first step, the input data consisting of a list of activities with location
alternatives and associated place utility values, a flow matrix and a list of critical activity
pairs is transformed into a working set W00 , which is assigned to the root node of the
branch and bound tree.

Step 2.0 The activity data sets are transformed into a linked-list format by generating
a set Sk for each activity k. Sk consists of elements for each alternate location of activity
k, which contain the cell subareas, the utility place value and the alternate centroid.

Step 3.0 Based on the critical pairs, feasible pairwise combinations of alternate activ-
ity locations are determined. An associated utility value of each alternate activity combi-
nation is computed. Based on these combinations, the working set W00 = {S 1 , S 2 , ..., S n }
where S k is the set of all activity alternate pairs for the k th critical pair of activities is

Step 4.0 Three heuristics can be selected for the expansion of the root node. Assume
|S 1 | = r, then r branches emanate from the root node, while the remaining {S 2 , ...S n }
sets are reduced from elements which conflict with the element selected from S 1 . In brief,
this process continues until the bottom of the tree is reached, infeasibility is discovered
or lower-bounding indicates sub-optimality of a branch.

Step 5.0 The bounding process computes a lower bound for each node in the tree.
The most valuable of the remaining alternates is selected and its utility value added to
the partial solution.

Step 6.0 If the selection of elements results in an empty set of remaining activity
alternate pairs after the pruning operation, all elements which were marked as conflicting
with the current assignment have to be unmarked. The current assignment is marked as
infeasible. The selection routine is then called to find another assignment. If no other
assignment is to be found, the process backs up to the previous set of the branch.

Step 7.0 The solution computed by MAFLAD is presented to the user in a list format,
indicating the positioning of the optimal solution and three suboptimal solutions.

Several well-known problem instances (e.g. Nugent et al. [15] and Bazaraa [1]) were
used to test the computational behavior of MAFLAD. In several cases, the optimal
solution was achieved very quickly. In the case of an excessive number of alternatives,
however, MAFLAD will require an exponential amount of time for computation of the
optimal solution. Incorporating user interaction with the branch and bound process is
seen as a siginificant advantage to improving the usability of the approach. This user
interaction is described in the next section of the report.

2.4 Problem Statement

This proposal is mainly concerned with improving certain properties and aspects as-
sociated with the usability of MAFLAD. The following opportunities for improvement
were identified:

User Interaction In the current version of MAFLAD, the user interacts with the
program over a regular DOS-window. This form of interaction is little appealing and
insufficient for a standard software package.

Solution Output The solutions computed by MAFLAD are presented to the user in
the form of a list. A graphic output is not possible at this point of time. A visualization
of the optimal layout would be of great benefit to the user.

Input Data One the of the reasons for MAFLADs superior performance lies in the
pre-defined sets of alternate activity locations. The solution output may indicate oppor-
tunity for improvement by adding an alternate location to the current set. Currently,
the user is not able to go back and tweak the input data in a simple and convenient way
after the solution has been presented.

2.5 Conclusion
This section has reviewed several models for the analysis of the facility layout problem
along with a number of optimal and suboptimal algorithms for its solution. The facility
layout problem is a very difficult combinatorial optimization problem, which to date can
only be solved for fairly small problem instances. One of the most promising and efficient
approaches to solve the problem lies in the field of branch and bound algorithms, such as
MAFLAD. MAFLAD is an exact algorithm, which makes use of a pre-defined clustering
of alternate activity locations to decrease the computational complexity behind the
facility layout problem. Finally, several opportunities for improvement related to the
usability of MAFLAD were identified.

3 Project Proposal
3.1 Purpose and Goal
The purpose and goal of this project was to program an interface that facilitates the
users interaction with MAFLAD. Several features were added to the current version of
MAFLAD to improve its overall usability. It was aspired to deliver a software solution
with an appearance, usability, and computational efficiency that is comparable to stan-
dard commercial software packages. The interface is the only part of the program that
is visible to the user.

3.2 Current Version of MAFLAD

In the original version of MAFLAD, the user interacted with the program over a
regular DOS-window. The user was required to specify the name of the problem input
file, decide over one of three possible search heuristics (i.e. greedy heuristic, best future
value heuristic, limited lookahead heuristic), and indicate whether he wishes a graphic
display of the solution output (this option was not installed/functioning in the past).
MAFLAD is written in Fortran 77 and runs with any standard Fortran compiler.

The problem input files are stored in regular text-formats and contain all information
required to run the programm, i.e. the alternate locations for the set of activities, the
critical pairs of activities, the utility values, and the flow matrix. In the past, the
choice over one of the three heuristics was input as a numerical value by the user (1
= greedy heuristic, 2 = best future value heuristic, 3 = limited lookahead heuristic).
In the case of the limited lookahead heuristic, the user also had to specify how many
steps the algorithm was supposed to look ahead. The program then output the optimal
solution along with the time required to run MAFLAD to a data file called maflad.sol.
The solution was presented in a list format, which contained the optimal locations per

activity of the solution layout. For a more detailed presentation of the subroutines
incorporated in the MAFLAD code, please refer to Smith and Garcia-Diaz [19].

3.3 Programming Approach

The interface is programmed in Visual Basic 6.0, a programming language that lends
itself to the creation of interfaces with an underlying Fortran program. The initial
MAFLAD code is used as a subroutine and called from the Visual Basic interface. Visual
Basic provides a professional windows appearance and thus adds to the user friendliness
and usability of MAFLAD. Since this is a mixed language programming approach, there
are always some risks involved in the communication between the Visual Basic and the
Fortran part of MAFLAD. In principle, however, passing arguments between Visual
Basic and Fortran code is not problematic.

3.4 Program Features

The following features were implemented to improve the aspects listed in section 2.4.

User Interaction The interface steps the user through the input process. All spec-
ifications made by the user are passed on as arguments to the Fortran routine, which
then computes the optimal facility layout and passes the results back to the interface.
The user is able to load an existing problem or create a new problem file over the inter-
face. At any point, the user is able to go back in the menu and change his choices and

Solution Output As pointed out earlier, the Fortran subroutine writes the solution
into a file called maflad.sol. Based on this file, the Visual Basic program draws a
graphic output of the solution computed by MAFLAD and presents it to the user over
the interface. A graphic display of the solution is of great benefit for the user. Based on
the graphic display, the user might see opportunity for improvement by adding alternate
activity locations.

Input Data If the graphic output indicates opportunity for improving the optimal
solution by adding an alternate activity location, the user can change the data in the
input file over the user interface in a convenient way. The user can make changes to the
set of activities, add or remove alternate locations, and change the flow matrix or utility
values. The interface automatically updates the information in the respective source
file, which can then be used to rerun the model with the altered input information. As
stated earlier, one of MAFLADs key strengths lies in the pre-defined set of alternate
activity locations. Since the interface allows for a convenient way for the user to go back
and tweak the input data after the program has been run, this strength is preserved.

3.5 Conclusion
The usability of MAFLAD was improved by an easy-to-use interface that enables
the user to run MAFLAD, create new source files, edit existing input files, and view
a graphic output of the solution set. The option of editing the input data enables the
user to improve a solution provided through MAFLAD by adding alternate locations to
the set of activities. The ability to change the input file after an optimal solution has
been presented allows for a manageable number of alternate locations per activity in the
initial input file. The manageable number of alternate locations per activity is one of the
foundations of MAFLADs superior performance. With the ability to modify the input
data after a solution has been found, this property can be maintained and yet a potential
improvement of the presented solution set becomes possible. With these improvements,
the current version of MAFLAD has been significantly updated and enhanced.

4 Project Results
4.1 Introduction
Section 3 of this report provides an ex-ante look at the goals of this project. It gives
a concise overview of the different features that the final version of G-MAFLAD was
intended to contain in order to optimally enhance the original version of MAFLAD.
Chronologically speaking, the following section was written after G-MAFLAD was pro-
grammed and thus contains an ex-post view at this project. The intention of this section
is to portray the different features that G-MAFLAD offers to the user. In this sense, it
can be used as a manual if questions should arise when using G-MAFLAD. To ensure
the usability of this manual, all explanations are supported by screen shots taken from
the actual program. The reader is practically stepped trough the the process of using
G-MAFLAD. Furthermore, this section explains why the actual implementation of the
program in some ways differs from the initial plan summarized in the past proposal.

4.2 Proposal versus Implementation

4.2.1 Compliance with Proposal
In principal, all features contained in the proposal were successfully programmed and
can now be conveniently used. The purpose of the project was to develop a graphic user
interface that allows the user to

run a problem file,

edit an existing problem file,

create a new problem file,

receive a numeric solution output,
receive a graphic solution output, and
have the option of printing the solution ouput.
All these features are offered through a visually appealing graphic user interface that is
easy to use and in most cases self-explanatory. With respect to the actual program, the
implementation fully complies with the project proposal. The initial version of MAFLAD
was greatly enhanced and improved, since the whole functionality of MAFLAD can now
be used in a much more convenient way. In addition, the fact that the user receives a
graphic image of the output furthers the understanding of specific problems and adds to
the usability of MAFLAD. These results, however, could only be achieved by changing
the programming approach described in the proposal as explained in the next para-

4.2.2 Non-Compliance with Proposal

During the course of programming, it became very clear that the initially proposed
programming language of Visual Basic was not sufficient for this project. Generally
speaking, Visual Basic is a fairly simple language that allows convenient programming
of graphic user interfaces. However, the functionality offered by Visual Basic cannot cope
with higher level languages, which, for example, allow object oriented programming. For
this project, it has been very important to make use of this form of programming, since
the input and output files had to be represented by logical data types. As a result,
a new language that combined two factors had to be chosen. On the one hand, this
language had to contain elegant routines to program graphic user interfaces. On the
other hand, it had to allow higher level programming in the form of object oriented
approaches. Based on these requirements it was decided to continue the programming
with Visual C# (Visual C Sharp), a language that strongly resembles Java. Visual C #
contains a number of very powerful graphic routines and programming libraries that can
easily be accessed and are very well documented. In addition, it fully supports object
oriented programming. The development environment that was used to program the
interface is Microsofts Visual Studio .Net, which basically offers the same functionality
as Microsofts Visual Studio only that it is slightly more up to date.

4.3 Program Features and Functionality: Users Manual

In what follows, the functionality and features of G-MAFLAD are explained in great
detail. This section can be used as a manual and as a reference for troubleshooting.
It was attended to ensure the comprehensibility of all explanations. The goal of this
section is to enable a new user to install, use and understand G-MAFLAD. As pointed
out earlier, all explanations are supported by screen shots of G-MAFLAD.

4.3.1 Installing G-MAFLAD
The installation process of G-MAFLAD is very simple and will only take a few mo-
ments. G-MAFLAD runs on any machine that is equipped with a Windows XP/2000/98
or 95 operating system. No development environment or additional compiler are needed.
On most computers, however, the user will have to install the Microsoft .Net Framework
1.1 or any higher version thereof. On systems that were installed after January 1st,
2005, this framework should already be installed. The same holds true for users who
regularly update their Windows system. To install the .Net Framework 1.1 the user has
to visit the home page of the Microsoft Corporation and search for the framework under
Downloads. The installation file has to be downloaded and then started by opening
it. The installation file will then automatically recommende a folder under which the
framework should be saved.

After installing the framework, the user will only have to save the following files in a
single folder in order to run G-MAFLAD:

(1) GMAFLAD.exe

(2) MAFLAD.exe

(3) Inputbox.dll

(4) nunit.framework.dll

. The first file is the compiled executable file of the graphic user interface, the second file
is the compiled executable file of the Fortran code behind MAFLAD. The last two files
both are dynamic link libraries whose components are frequently used by the graphic
user interface. All files are contained in the compact disc enclosed in this report. The
user simply has to copy the folder G-MAFLAD to his system. After copying the folder,
the user may create an icon of GMAFLAD.exe on his desktop, which is recommended
if frequent use is to be expected. The reader should see the Appendix A of this report
for further references on the enclosed compact disc.

4.3.2 Starting G-MAFLAD

G-MAFLAD is started by double-clicking on GMAFLAD.exe or on the desktop icon if
one has been created. After G-MAFLAD has been started, the user sees an introductory
screen as presented in Figure 1. The simple purpose of this screen is to welcome the
user to G-MAFLAD. The puzzle was chosen as a symbol for optimally organizing a set
of activities. The actual program is then started by clicking on the Begin button.

Figure 1: Introductory Screen

4.3.3 The Main Interface

The main interface can broadly be divided into two parts as can be seen in Figure
2. The upper part offers a set of buttons and checkboxes that allow the user to specify
various input options as well as to make use of all features offered by G-MAFLAD. The
lower part of the interface is solely concerned with presenting the numeric and graphic
output of G-MAFLAD. In the left upper corner of the interface an array of actions
has been programmed to provide a visually appealing and simple access to the main
features provided by G-MAFLAD. Next to the action buttons, the user can select one
out of three heuristics as described in the proposal. Upon starting G-MAFLAD, the
greedy heuristic is always selected as the default heuristic. In the upper right corner,
the user can make further specifications concerning the solution output. Since it is
generally expected that the user will wish to receive a numeric and graphic output, the
respective checkboxes are also selected by default upon starting G-MAFLAD. Under
the drop down menu File at the top of the interface most of the features provided by
G-MAFLAD can also be selected, if the user finds this to be more convenient. In what
follows, the different features and actions provided through G-MAFLAD are portrayed
and explained in greater detail.

Figure 2: The Main Interface

4.3.4 Opening and Closing an Input File

An input file which the user wants to run by using G-MAFLAD can be conveniently
opened by pressing the Open button or by choosing the same command via the File
drop down menu. All input files have to be data files, i.e. they must have a .dat-ending
in order to be accepted by G-MAFLAD. In addition, an acceptable input file has to be
structured along a pre-specified fixed pattern in order to be readable to the underlying
Fortran code. This structure is described more closely in Section 4.3.7 of this report.
As can be seen in Figure 3, the regular Windows Open File interface appears upon
pressing the Open button. If a file that a user expects to be shown under a specific
folder does not appear, this is most probably due to the fact that it is not a regular
data file and can thus not be used by G-MAFLAD. After a file has been selected, the
path and name of the file are shown under the caption Selected Input File in the main
interface. Except for creating new input files, all features can only be used after an input
file has been selected. If a file has been opened it can be closed by pressing the Close
button or again by choosing the equivalent command from the File drop down menu.
Finally, the program can be exited at any time by pressing the Exit button on the

Figure 3: Opening an Input File

main interface.

4.3.5 Running an Input File and Receiving Output

As pointed out in the preceding paragraph, a problem can only be run after an input
file has been selected. Before pressing the Run button, the user has to specify the
heuristic he wishes the problem to be solved by. There are three heuristics to choose

Greedy Heuristic

Best Future Value Heuristic

Limited Lookahead Heuristic

The choice over the heuristic is exclusive, i.e. only one heuristic can be chosen at a
time. Therefore, if the user selects a heuristic, any selection that was made prior to

this selection will be deleted. If the user decides to run the problem by using the
Limited Lookahead Heuristic, he is prompted to enter the number of steps he wishes
the algorithm to look ahead as shown in Figure 4. In addition to selecting a heuristic,

Figure 4: Selecting the Limited Lookahead Heuristic

the user can also make further specifications concerning the output he wishes to receive.
In some cases it makes sense to limit the time allotted to the algorithm to solve the
problem. This can be done by checking the box next to Limit Solution Time in the
solution options array. If the user chooses to limit the solution time, he is prompted
to specify the maximum time in seconds he wishes the algorithm to run as shown in
Figure 5. If the time required to optimally solve the problem exceeds the solution time
specified by the user the algorithm is terminated prematurely. After an input file has
been selected and further specifications have been made, the user can press the Run
button in order to receive a numeric and graphic solution to the given input file.

The numeric solution is displayed in the lower left corner window which is labelled
Numerical Solution. The graphic solution is displayed in the adjacent window which

Figure 5: Limiting the Solution Time

is labelled Graphical Solution. Figures 6 and 7 show how the numeric and graphic
output are displayed in the interface for the input files Bazz1.dat and Bazz3.dat. The
numeric output is directly imported from the solution file that is automatically built
by the underlying Fortran code. The MAFLAD.sol file contains the optimal allocation
of activity alternates for the given problem. The solution file itself, however, does not
contain any valuable information without knowledge of the respective input file. This
is due to the fact that the solution file only shares the optimal alternate per activity
with the user without indicating the cells associated with the different alternates. While
programming the routine that allows a graphic display of the optimal solution, this
certainly had to be taken into account. G-MAFLAD reads the optimal solution from
MAFLAD.sol, saves the optimal alternates and then goes into the original input file
and reads the set of cells associated with each optimal alternate. This is only possible
because each input file is defined by a fixed logical pattern. Based on the information
taken from the input file, the graphic routine first draws a grid of the size defined in
the problem file. The horizontal and vertical axes represent the columns and rows of

Figure 6: Numeric and Graphic Output for Bazz1.dat

Figure 7: Numeric and Graphic Output for Bazz3.dat

the grid and are labelled with numbers that indicate the position of each cell. In the
case of bazz1.dat, for example, the grid has 10 columns and 6 rows, i.e. it is 10 cells
long and 6 cells wide. The counting of the cells begins in the lower left corner with cell
1 and proceeds horizontally from left to right to the upper right corner with cell 60.
The location of each alternate is pre-defined in the input file by means of this counting
mechanism. Based on the information provided by MAFLAD.sol, G-MAFLAD reads
the numbers associated with each optimal alternate from the input file and borders
each optimal set of cells with a black line. In the center of each set, the number of
the respective activity is displayed. In the case of L-shaped activities, the number is
displayed in the center of the larger part of the set of cells. Cells that remain unused in
the sense that they are not occupied by any activity alternate are colored grey.

The solution to bazz3.dat does not only contain one optimal solution but provides
up to four possible solutions to the user. The numeric solution is again taken from
MAFLAD.sol and can be viewed by scrolling down the bars adjacent to the left hand
window. The graphic routine also offers an image of the four solutions provided by
the algorithm, which can be viewed by clicking the Previous and Next buttons
depending on the number of the solution that is currently being displayed. In Figure
7 the user has pressed the Next button once in order to view a graphic image of the
second solution provided by the algorithm. If the user wishes to run another problem
file he can simply open another input file by pressing the Open button. The current
input file will then automatically disappear.

4.3.6 Printing and Saving the Output

In the previous sections, the benefit of having a graphic image of the optimal solution
provided by G-MAFLAD has already been pointed out. A graphic image, however, is
of little use if it cannot be saved or printed. Therefore, the interface offers a Print
and Save Output option to the user. Upon pressing the Print button the regular
Windows printing interface is opened and prompts the user to specify further printing
options, such as the selection of a printer. The printing routine included in G-MAFLAD
combines the numeric and graphic output into a single file, which is more convenient for
the user than having to print two files.

In addition to the option of printing the solution output, the user can also save the
graphic output as a .GIF image by pressing the Save Output button which activates
the regular Windows saving interface. The option of saving the solution is only related
to the graphic output. The separation of the numeric and graphic output has clear
advantages and was programmed on purpose. Since the numeric output is contained in
the MAFLAD.sol file it would not have made much sense to save it as part of a .GIF file
which cannot be altered. In addition, the graphic output can now be easily imported

into publications without necessarily having to display the numeric solution. Figure 8
shows a copy of the graphic output after it has been saved as a .GIF file.

Figure 8: GIF-File of Graphic Solution Output for Bazz1.dat

4.3.7 Editing an Existing and Creating a New Input File

One of the key strengths of G-MAFLAD is that it allows the user to conveniently edit
an existing input file as well as to create a new input file that is structured along the
fixed pattern required for a file to be read by MAFLAD. Before the different steps that
need to be taken in order to use these features are portrayed, the structural pattern
behind an input file is explained in detail in the next paragraphs.

The Structure of Input Files

A MAFLAD input file contains a complex set of data that is always identically struc-
tured. This allows the underlying MAFLAD algorithm to read and process an input
file and provide a solution to the reader. A valid input file has to contain five pieces of

the grid size

the activity sizes

the alternates per activity

the utility values per alternate and

the flow matrix

Figure 9 illustrates how these pieces of information are allocated within the input file
for the example of bazz1.dat. Since the entire input file could not be displayed due to
its size only an elliptic excerpt is included in this report. In the first line of the input

Figure 9: Excerpt from Bazz1.dat (Elliptic)

file, the number of columns and rows of the grid is defined. In this case, the grid has
10 columns and 6 rows. The definition of activities begins with the second line, which
in this case states that activity 1 can be placed at 6 alternate locations. The cells
associated with these locations are then defined in the succeeding lines which each begin
with the number 9, indicating that activity 1 has a size of 9 cells. The first location,
for example, consists of cells 1, 2, 3, 11, 12, 13, 21, 22, and 23. As pointed out earlier,
the counting of cells begins in the lower left corner of the grid. This specific set of cells
therefore represents a 9 cell square which is situated in the origin of the coordinate grid
system. The placement utility values related to each alternate location can be directly

found in the line below each set of cells. In bazz1.dat, all utility values are zero. After
all activities have been defined based on this fixed pattern, the matrix containing the
flows between the activities is added to the file. A row of three -1s indicates the start
and end of this flow matrix. In this specific case, for example, there is a flow of 288.00
between activity 1 and activity 2. The reader should also review section 2 for detailed
information on the algorithmic structure behind MAFLAD and on how flow and utility
values are incorporated into the objective function.

The great advantage of G-MAFLAD is that a user can edit an existing or create a new
input file without having to care about the structure of the input file, since G-MAFLAD
automatically incorporates all changes and input values into the fixed pattern. With
this background on the structure of input files, the report now proceeds with explaining
how input files can be changed and created.

Editing an Existing Input File

In order to edit an existing input file, it first has to be opened by pressing the Open
button on the main interface. Upon pressing the Edit button a new interface appears
as shown in Figure 10. The path and name of the file that was selected prior to pressing
the Edit button is shown in the top part of the interface under the label File. The
editing interface automatically creates a grid in the size of the input file that was selected.
This grid is the users work bench if changes are to be made to the set of activities and
alternates. G-MAFLAD allows the user to edit all pieces of information included in an
input file. The user can
change the grid size

add and remove activities

add and remove alternate locations

change the placement utility value of each location and

change the flow matrix.

This provides a high degree of flexibility to the user, since he can alter the input file in
any thinkable way.

Changing the Grid Size The grid size can be changed by using the input boxes
in the left upper corner of the interface. The grid size is defined by a number of columns
and rows. If the user decides to change the grid size, he is warned that all activities
will be deleted by this action. This functionality therefore only makes sense if a user is
editing a file with few activities whose file name he intends to preserve via this way.

Figure 10: Interface for Editing the Bazz1.dat Input File

Adding and Removing Activities An activity can easily be removed by pressing

the Remove button in the activities field. An activity can only be removed after it has
been selected, which is why the Remove button is only activated after an activity has
been selected by clicking on its number. If an input file has a large number of activities,
the user will need to scroll down the bars next to the activity box in order to view all of
them. Upon selecting an activity the first alternate location of this activity is displayed
in the coordinate grid system as shown in Figure 11. If the user intends to remove an
activity, all data associated with this activity will be deleted from the input file, i.e. all
alternate locations, all utility values, and all flow values. As stated earlier, G-MAFLAD
updates the input file based on the users input. After deleting an activity, the file can
still be read by MAFLAD, since the required structure is preserved. The user can add an
activity to the current set by pressing the Add button in the activities field. By doing
so, the user is prompted to define the size of the activity by entering a number of cells.
Once he confirms his input, he is informed that a new activity has been added to the
set. A new activity is always given the highest number within the set. The shape of an

Figure 11: Interface After Activity 1 of Bazz1.dat Has Been Selected

activity is not generally defined but left open to ensure a high degree of flexibility when
selecting the alternate locations for each activity as described in the next paragraph.

Adding and Removing Alternate Locations A less abrasive change of the

input file can be reached by removing only a certain number of alternate locations
instead of removing an entire activity. In order to do so, the user first has to select
an activity and then choose the alternate location he wants to remove by clicking on
the alternates number. Again, all alternate locations can be viewed by scrolling down
the bars connected to the box. As the user clicks on the number of an alternate, the
location of this alternate is displayed in the coordinate grid system. This way, the user
can always check wether he has chosen the correct alternate before deleting it. Before
the user can delete an alternate, he is again prompted to confirm his decision. Upon
deleting an alternate, the respective input file is updated by G-MAFLAD. Adding an
alternate can be done in a very convenient way. The user first has to select an existing
or create a new activity to which he wants the alternate to be added. Once he has done

so, he can add an alternate by pressing the Add button in the alternates field. The
program then prompts the user to select a number of cells in the size of the respective
activity. Once the user has selected the last cell the alternate is automatically added to
the input file as shown in Figure 12. An alternate location can take on any shape as long

Figure 12: Interface after Alternate was Added

as the selected cells are adjacent to each other. In this way, an activity can be L-shaped,
T-shaped, or U-shaped. Needless to say that it can also have the shape of a square or
a rectangle. It is, however, not possible to allocate two cells in a diagonal direction. In
this case, the user will be prompted to select a different cell. The utility value of each
alternate is displayed in the alternates field under the label Utility Value. In addition
to adding and removing alternates, the user can also change the associated placement
utility value by pressing the Change button in the alternates field. As shown in Figure
13 the user can enter the new utility value via a regular input box. If an alternate is
added to an activity without updating the utility value the default placement utility
value is zero.

Figure 13: Changing the Placement Utility Values

Updating the Flow Matrix The flow matrix is the final piece of information
that needs to be taken care of if editing an existing or creating a new input file. The
user should note that an update of the flow matrix is only necessary if an activity has
been added. The values contained in the matrix are not determined by flows between
alternate locations, but by flows between activities. This implies that a flow matrix does
not have to be updated if only an alternate location of an activity has been removed or
added. An update of the flow matrix can be done by pressing the Edit Flow Matrix
button on the right part of the interface. Upon pressing the button the flow matrix
appears as shown for the example of Bazz1.dat in Figure 14. Although the structure
of the flow matrix as presented by G-MAFLAD may appear a little complex at first,
G-MAFLAD offers a fairly simple tool for editing the flow matrix. As indicated by the
labels From and To all flows contained in the matrix are displayed. The user can
remove any flow by pressing the associated Remove button located next to each flow
value. Any flow value can be changed by selecting the two activities between which the
flow takes place from the drop down menus in the bottom part of the interface. By

Figure 14: Editing the Flow Matrix for Bazz1.dat

clicking on the arrows and scrolling down the user can view all activities and form the
required activity pairs to change a flow value. The new utility value is entered into the
box next to the drop down menus. By pressing the Add button, a new flow is either
added or an existing flow is updated after the user has given his final confirmation.

Saving Changes G-MAFLAD notices any change that is made to an input file.
The user has different options of saving these changes. If the user has made changes to
an input file and does not actively save them, he is automatically asked if he wishes to
save the changes when exiting the program. Changes can either be saved by pressing
the Save or the Save As button on the interface. It his highly recommended to
save changes under a different file name by using the Save As button, because the
initial input file will be overwritten if the Save button is used. The user should also

notice that the name of an input file can only have a maximum of 5 characters, since
the underlying MAFLAD code can only read names up to this limit. If the user enters
a longer name, he is prompted to choose a shorter one.

Creating New Input Files

The creation of new input files is very similar to editing an existing input file. In order
to create a new input file, the user has to press the New button on the main interface.
Upon doing so, a new interface opens as shown in Figure 15, which is identical with the
interface that opens when editing an existing input file only that is completely blank.
Based on this interface, all values required for a valid input file can be entered. The

Figure 15: Creating a New Input File

grid is automatically drawn out after the user has entered values for columns and rows
and pressed the Resize button. The process of adding activities and alternates is very
similar to the process of editing an input file as described in the preceding section. Most
of the features are self-explanatory, which is why they are not explained in this section.

4.4 Programming Methodology
The last sections were mainly concerned with presenting the different features offered
by G-MAFLAD to the user. This section will provide a brief overview of the program-
ming methodology behind G-MAFLAD. The user can also view the underlying source
code which is contained in the enclosed compact disc for further information.

G-MAFLAD consists of two parts: The first part is the underlying MAFLAD algo-
rithm, which was initially programmed in Fortran 77 (fixed format) and for the sake of
simplification and usability was converted into Fortran 90 (free format). The second part
consists of the graphic user interface (GUI), as presented in the preceding sections. This
project was only concerned with programming the user interface. The actual MAFLAD
algorithm was programmed and created by Smith and MacLeod [20]. Only very few
changes had to be made to the underlying Fortran code in order to establish the com-
munication between the interface and the algorithm. Once the user presses the Run
button on the main interface, G-MAFLAD calls the MAFLAD.exe file and transfers the
required input data to the algorithm. The algorithm then computes an optimal solution,
if one exists, and informs the interface about the location and name of the solution file
MAFLAD.sol. G-MAFLAD can also terminate the algorithm prematurely by closing
the executable MAFLAD file if the user has limited the solution time. During the com-
putation of the optimal solution, no actions within the interface can be taken. This is
due to the fact that the executable MAFLAD file runs as a routine within G-MAFLAD.
If the user needs to terminate the program before an optimal solution has been found,
he will have to close the DOS-window that was opened upon pressing the Run button.
Again, this can be avoided by limiting the solution time prior to running a problem.

5 Conclusion
5.1 Introduction
The purpose of this project was to program an interface that allows a simple and
convenient use of MAFLAD. The project started with a review of the literature pub-
lished in the field of layout optimization. In the second section of this report, a problem
statement was formulated based on the insights from several scientific publications. The
third section was related to stating the purpose and goal of the project. Section 4 pre-
sented the results that were achieved through the process of programming the interface.
Theoretical and practical skills were equally required to fulfill the requirements of the
project. Theoretical skills in the sense that a large number of literature references had
to be studied in order to gain an excellent understanding of the layout optimization
problem. And practical skills in the sense that a user friendly graphic interface had to
be programmed. Based on this structure, the project formulation provided great condi-

tions for testing the skills of an industrial engineer who should equally be endowed with
a theoretical understanding of complex problems and practical skills to find appropriate
solutions. In what follows, the results of the project are evaluated and the report is
closed with some concluding remarks.

5.2 Project Critique

The project critique is a very important part of this report, since it clarifies to which
degree the goals put forward in the proposal were reached. Five main areas for evaluation
were identified:

Program Functionality

Program Usability

Program Appearance and

Program Compatibility

The term Program Functionality refers to the features offered by G-MAFLAD. In

essence, all features included in the initial version of MAFLAD can be easily used through
the interface. Furthermore, G-MAFLAD enhances the original version by providing a
graphic solution output to the user as well as by providing a feature to edit existing
and creating new input files. In conclusion, all requirements put forward by the project
proposal have been fulfilled with respect to the criterion of Program Functionality.

The usability of programs has become an increasingly important factor for the quality
of software products. One of the key goals of this project was to design an interface
with a high degree of usability. It was intended to allocate the buttons and windows
of the interface in a clear and self-explanatory way. Whether this criterion has been
sufficiently fulfilled, however, strongly depends on the individual users opinion and can
thus not be answered satisfactorily by a single author or user.

The third criterion is concerned with the overall appearance of G-MAFLAD. Since
Visual C# is part of the Microsoft Visual Studio family of programming languages, the
appearance of the interface is consistent with the appearance of any other Windows
application. The graphic routine delivers a clear image of the solution output, which
adds to the professional appearance of G-MAFLAD.

G-MAFLAD runs on any machine that is equipped with a Windows operating system.
In principal, G-MAFLAD therefore has a high degree of compatibility. The installation
of G-MAFLAD, however, requires that the Windows system is updated with the Mi-
crosoft Visual Studio .NET framework. Since G-MAFLAD is not a commercial software
package, this framework is not enclosed in the G-MAFLAD compact disc. At this point,
the project certainly reaches its limits and cannot cope with the installation features
provided through a commercial software package.

Apart from the program features, an evaluation of this project should also determine
whether the project was completed in a timely manner and in accordance with the
predetermined project time line. Unfortunately, the completion of this project exceeded
the expected date of completion by two months. After all, it has been more important
to deliver an excellent software package instead of finishing the project on time with an
inferior solution. Nevertheless, based on the time criterion the completion of the project
did not meet the proposals expectations.

5.3 Concluding Remarks

The future use of G-MAFLAD will determine in how far the project has added true
value to the original version of MAFLAD by this project. Throughout the process of
programming the intention has always been to fulfill or exceed the requirements put
forward by the project proposal. The analysis in the preceding section has shown that
this endeavor has been successful to a certain degree. The report now closes with the
hope that users will enjoy working with G-MAFLAD and that more features might be
added to the current version in the near future.

[1] M.S. Bazaraa. Computerized layout design: A branch and bound approach. AIIE
Transactions, 7:432438, 1975.

[2] M.S. Bazaraa and H.D. Sherali. On the use of exact and heuristic cutting plane
methods for the quadratic assignment problem. Journal of the Operational Research
Society, 33:9911003, 1982.

[3] N. Christofides. Combinatorial Optimization. Chichester, New York, 1979.

[4] J. Delvecchio Smith. A Parallel Branch and Bound Algorithm for the Quadratic
Set Packing Problem. PhD thesis, University of Massachusetts Amherst, Amherst,

[5] C.S. Edwards. A branch and bound algorithm for the koolmans-beckman quadratic
assignment problem. Mathematical Programming Study, 13:3552, 1980.

[6] R.L. Francis and J.A. White. Facility Layout and Location. Prentice-Hall, Engle-
wood Cliffs, 1974.

[7] P.C. Gilmore. Optimal and suboptimal algorithms for the quadratic assignment
problem. Journal of the Society for Industrial and Applied Mathematics, 10:305
313, 1962.

[8] L. Kaufman and F. Broeckx. An algorithm for the quadratic assignment problem
using benders decomposition. European Journal of Operational Research, 2:204
211, 1978.

[9] O. Kettani and M. Oral. Reformulating quadratic assignment problems for efficient
optimization. IIE Transactions, 25:97107, 1993.

[10] T.C. Koopmans and M. Beckman. Assignment problems and the location of eco-
nomic activities. Econometrica, 25:5376, 1957.

[11] A. Kusiak and S. Heragu. The facility layout problem. European Journal of Oper-
ational Research, 29:229251, 1987.

[12] E.L. Lawler. The quadratic assignment problem. Management Science, 9:586599,

[13] R.D. Meller and K.Y. Gau. The facility layout problem: Recent and emerging
trends and perspectives. Journal of Manufacturing Systems, 15:351366, 1996.

[14] G.L. Nemhauser and L.A. Wolsey. Integer and Combinatorial Optimization. Wiley,
New York, 1988.

[15] C.E. Nugent, T.E. Vollmann, and J. Rural. An experimental comparison of tech-
niques for the assignment of facilities to locations. Operations Research, 16:150173,

[16] P. Pardalos and H. Wolkowicz. Quadratic assignment and related problems. In DI-
MACS Series in Discrete Mathematics and Theoretical Computer Science. Ameri-
can Mathematical Society, 1994.

[17] C. Roucairol. A parallel branch and bound algorithm for the quadratic assignment
problem. Discrete Applied Mathematics, 18:211225, 1987.

[18] S. Sahni and T. Gonzalez. P-complete approximation problems. Journal of the

Association for Computing Machinery, 23:555565, 1976.

[19] J.M. Smith and A. Garcia-Diaz. Computerized layout procedures. unpublished

incollection, October 2004.

[20] J.M. Smith and R. Macleod. A relaxed assignment algorithm for the quadratic
assignment problem. INFOR, 26:170191, 1988.

[21] J.M. Smith and R.P. Pelosi. Conversational optimization and layout planning.
Environment and Planning, B11:6386, 1984.

A G-MAFLAD Compact Disc
Enclosed in this report is the G-MAFLAD compact disc, which contains all files necessary
to successfully install G-MAFLAD on the users system, except for the .NET framework,
which has to be downloaded from the home page of the Microsoft Coporation if not
already installed on the users system. The user should also read Section 4.3.1 of this
report on how G-MAFLAD can be installed. The following folders are contained in the
compact disc:

(1) ReadMe


(3) Problem Library

(4) Source Codes

The folder ReadMe provides a reference on how G-MAFLAD can be installed. It

also contains a text file with further information about the programming methodology
behind G-MAFLAD as well as a copy of this project report. The folder G-MAFLAD
is the core piece of the compact disc. It contains the files necessary to run G-MAFLAD
on the users system. After saving this folder on the users system, G-MAFLAD can
then be started by opening the GMAFLAD.exe file. The user should save this folder
on his system. G-MAFLAD can then be started by opening the GMAFLAD.exe file.
The third folder provides a number of standard input files which can be read and run
by G-MAFLAD. The problem files were taken from various sources, such as Bazaraa [1]
and Nugent [15]. The fourth and last folder named Source Codes contains the source
code of MAFLAD, which was converted into Fortran 90 and G-MAFLAD, which was
programmed in Visual C#. These codes are important for users who wish to add more
features to the current version of G-MAFLAD.