Introduction to Engineering Systems II

EG 10112

Section 1

Professor Seelinger

Group 4

Travis Tredway, Maggie Thomann, Amelia Eginton, Caroline Braun, Zack Jones

Inventory Control for Community Partners of Dallas

April 28, 2015

Signatures:

Travis Tredway

Maggie Thomann

Amelia Eginton

Caroline Braun

Zack Jones

I. Abstract

Community Partners of Dallas (CPD) is a nonprofit organization located in Dallas, Texas

with the mission of ensuring safety, restoring dignity, and inspiring hope for the more than

20,000 abused and neglected children served by Dallas County Protective Services.1 In line with

this mission, each year the organization hosts a Back To School Drive, which provides school

supplies and uniforms to around 2,400 students in the Dallas area. The CPD Back To School

Drive has quickly grown to be more than the organization can handle efficiently. Currently,

caseworkers submit information about their children via email and volunteers spend hours

perusing the submitted data to determine what supplies each student needs. Volunteers then

pack backpacks with supplies and uniforms. Oftentimes, however, due to the multiple layers of

communication, certain supplies and uniform sizes run out in the middle of the drive.

It is from here that the motivation for creating this GUI was derived. This GUI

streamlines the organization’s Back to School Drive by saving data in a central location, tracking

the inventory, and providing the organization with an optimal storage plan based on the amount

of items in stock. Due to an inability to test this model with actual data from the organization, a

standard of measuring “success” must be defined. Ultimately, though the real­world applications

of such a program are hard to deny, it was found that the GUI could be both more robust and

more practical. Further work could focus on a more systematic approach of analyzing the data to

ensure an optimal storage configuration is selected each time new information is input.

Following are details regarding the overall concept of the project through its design statement.

1

II. Overall Concept

The project goal was to generate a program that obtains information about what CPD

currently has in stock for the 2,400 children that the Back to School Drive benefits and report

back what they need in a clear and organized format. Furthermore, the program was created to

outline an optimal storage plan based on the dimensions of the storage space and CPD’s current

inventory. Below, Figure 1 is a flowchart that represents the methods through which a final

solution was achieved. This figure is referenced more extensively and explained in greater detail

in Section III.

Figure 1. Flowchart for Optimization Algorithm

Throughout the design process, a few changes had to be made. First, although not in the

initial plan, the creation of a caseworker GUI was deemed necessary. This allows caseworkers to

input the information for each child into the system. The initial GUI and the caseworker GUI

needed to be linked in order for them to function properly. Second, the initial plan was to create

2

a simulation that would allow the user to see the boxes being placed in their locations. A

program similar to tetris was considered; however, it took too long to run and it did not

consistently create the optimal storage plan. Another plan involved using an optimization

strategy based on chromosome coding to create the ideal layout; however, this code could not be

configured to include the three different shelves 3. A different algorithm, described in Section III

and graphically represented in Figure 1 above, was used for the optimization.

III. Underlying Concept

As alluded to above, in place of using a genetic algorithm to find an optimal

configuration for the given amount of boxes, a cost function was created that takes into account

the importance the user places on the location of boxes on the shelving unit. If the user places

low emphasis on the location of boxes, the program optimizes “for space”, simply filling the

shelving unit with as many boxes as possible. A high emphasis on location corresponds to an

optimization “for use”, where the size of each box plays a role in determining its final location.

In this model, an optimal small box is defined as one that is placed on the middle shelf. The cost

function created in this program synthesizes this information and outputs an optimal

configuration to the user based on this importance level. On a basic level, aspects of the

computational model include the dimensions of the boxes used, the dimensions of the shelving

unit, and the number of shelves in the warehouse. Before a cost function could be created, a few

assumptions had to be made. First, it was assumed that only three discrete box sizes would be

used: a small box (8” x 12” x 10”), a medium box (12” x 16” x 16”), and a large box (24” x 24”

x 20”). Further, it was assumed that only one shelving unit would be used that contained three

identical shelves of dimensions 40’ x 2’ x 3’. Finally, to ensure no smaller boxes were crushed

3

under the weight of their larger counterparts, it was assumed that boxes would not be stacked on

top of one another.

Figure 1 in Section II illustrates the thought process behind the optimization aspect of the

program. Initially, all boxes are stored along with their box sizes as a separate entry in a

structure array. Also stored in the structure array is an access constant, a value of 0.1 for small

boxes, 0.3 for medium boxes, or 0.5 for large boxes, where a smaller value corresponds to a box

that should be easily accessible to the user. A random solution is then generated that assigns

each box to one of the three shelves. Based on this random assignment, a location constant is

ascribed to each box, a value between 0 and 1 that describes the success of the placement of the

box based on the box’s location and the access constant of each box. Again, a smaller number

corresponds to a more optimal location. For example, a small box initially placed on the bottom

shelf is given a location constant of 0.5, while the location constant of a small box placed on the

middle shelf is 0.1. The cost function relates the emphasis the user places on box location, along

with the location constant and access constant of all of the boxes in the configuration. The cost

of a box is given by equation (1) below:

(x) (L ) (A 00)C = c * S + c * 1 (1)

where L c is the location constant of a given box, S corresponds to the “Location Importance”

slider value, and Ac refers to the access constant of a given box. The total cost of the

configuration is then calculated by summing the cost of each individual box. This cycle is

repeated a number of times based on an iteration value input by the user. After all iterations

have completed, the lowest total cost is selected and the configuration causing this minimal cost

is stored. To ensure this configuration does not exceed the maximum capacity of the shelves, the

4

numbers of optimal small, medium, and large boxes are input into numBoxesF, a function that

outputs the number of boxes of each type that can be placed on each shelf for the optimal amount

of area to be used. The function works by comparing the total area of each shelf to the area used

by the inputted number of boxes. The area of each box and shelf is given by equation (2) below:

lA = *w (2)

where l is the length of the object, and w is the width of the object.

The caseworker GUI, shown below in Figure 2 of Section IV takes the information that is

entered when the “submit” button is pressed and stores it in an array. When the “submit” button

is pressed, it also calculates all of the values that will be displayed in the “needed” column of the

optimization GUI, which can be seen in Figures 3 and 4 of Section IV. The information is passed

from one GUI to another through global variables, which can be accessed from any file. This was

the simplest way for the necessary variables to be entered in the caseworker GUI and accessible

in the optimization GUI.

IV. GUI Tool

This project contains two GUIs that are linked: one GUI is the interface through which

the caseworker inputs all of their information and is shown below in Figure 2. The other GUI is

the interface through which the optimization of the shelves and the inventory control is displayed

and is shown below in both Figure 3 and Figure 4. Each GUI was graphically designed using

imported .jpeg files designed in Microsoft PowerPoint and used as the background of each GUI.

The key features of the GUI in Figure 2 include the seven fields in which each case worker from

CPD inputs their information. The “Name,” “Your Unit,” and “Student Name” fields are all edit

boxes due to the infinite variability of these data points. The “Gender,” “Age,” “Grade,” and

5

“Uniform Size” fields are all drop­down menus so that the organization can be easily organized

and sorted for the organization to later use. As mentioned above, the information that the GUI

obtains here is organized into an array; however, this array is not displayed in the final GUI

output for the practical reason that there would not be enough room to display all of this

information. The number in the lower right hand corner of Figure 2 lets the caseworker know

how many times they have submitted information; the caseworker can submit one sheet of

information for each child. The “Submit” button, also in the lower right hand corner of Figure 2,

is used to generate a new, blank caseworker GUI and to submit the information, which is then

linked to the GUI displayed in Figures 3 and 4.

Figure 2. Caseworker GUI

6

Below, in both Figures 3 and 4, is the GUI that displays (1) a visual representation of the

shelving space being optimized and statistics associated with that, (2) data fields to enter new

donations, and (3) data fields that report back the current status of the inventory of the CPD.

Key features of this GUI include the visual representation of the optimization of the shelves in

the graph shown in the center of the GUI. In Figure 4, the graph is shown in 3D to demonstrate

the function that plots cubes 2. The color of each cube depends on the extent to which it is

optimized; for example, in Figure 3, the large green rectangles on the first shelf represent large

boxes that are optimized to their fullest extent because it was dictated by the organization that it

is best to have the large boxes on the lowest shelf. The orange color of some boxes represents

mediocre optimization, while the red color of other boxes represents that these boxes are in their

least preferred location. Beneath the storage visualization graph is a slider for the importance of

location and an edit box for the number of iterations. A slider was chosen for the user to easily

and quickly adjust the importance that location holds for each box, while an edit box was chosen

for the number of iterations, since the user will probably want to keep this number fairly high in

order for the algorithm to be the most effective. The last optimization feature of this GUI are the

two percentage values beneath this slider that allow the user to see the effectiveness of the

algorithm; the higher the percentage of storage space filled and the higher the number of optimal

small boxes, the more effective the algorithm is. Finally, the “Sort” button can be pressed in

order to run the algorithm and rearrange the boxes on the shelves in the graph.

7

Figure 3. Display of Optimization GUI

Another key feature of this storage visualization GUI depicted in Figures 3 and 4 are the

data fields on the right and left sides. The fields on the left side that are next to the school supply

item name (Example: “Backpacks”) are all edit boxes that allow the caseworkers to input new

numbers for any donations they may receive for the summer school drive. Changing these

numbers automatically adjusts the static text boxes at the lower left hand corner of the GUI in

Figure 4 so that they accurately represent how many boxes the organization will need to store all

these new items in addition to their current items. The fields on the right are static text boxes

that represent what the organization currently has in stock, what they need based on what each

caseworker inputs into the caseworker GUI depicted in Figure 2, and whether or not they have a

surplus or deficit of those items. This information is displayed only when the “Refresh” button

8

in the lower right hand corner is pressed after the caseworker inputs all the pertinent information

into the caseworker GUI.

Figure 4. 3­D Display of Optimization GUI

V. Discussion of Performance

One way to determine effectiveness of the algorithm is the percent of optimal small boxes,

which ideally is a rather high percentage. The results for this percentage varied significantly

each time the boxes were resorted. This inconsistency is a slight variation from the predicted

outcome, and it is due to the randomization aspect of the algorithm which completely

reorganized all the boxes each time the “sort” button was pressed. Therefore, the success of the

program can be difficult to determine because the randomization makes it harder to assess the

average percent of optimal small boxes depicted in the GUI.

9

Another consequence of the randomization was that the value of the slider determining the

relative importance of location did not have a significant impact on the percent of optimal small

boxes depicted in the GUI, which is the major difference in the results from the predictions.

In order to solve this randomization issue, the program could have made use of the “brute

force method.” This would involve the program cycling through every possible solution and

ranking each one based on its cost, but would thereby be sacrificing valuable time. After being

run both ways, the program was determined to be more effective when not using the brute force

method, which was vastly too time consuming and did not provide significantly improved

results.

In order to make the GUI more practical for the real­life warehouse, the information could be

entered and stored online, and the data could be entered into the GUI from one centralized

location later, or the GUI itself could possibly be run online. Doing either of these would avoid

the problem of each worker having to use the same computer in order for the GUI to collect all

the data. Another way to make the algorithm more practical would be creating a “box stacking”

option, which would incorporate the optimization of volume, opposed to only accounting for

area. Overall, despite the above discrepancies, the results of the GUI matched well with the

predictions listed in the initial project memo.

10

References

1. Community Partners of Dallas (2014) CPD: Overview. Retrieved April 25, 2015.

http://www.cpdtx.org/default.asp?contentID=5

2. Olivier (2007) File Exchange: Plotcube. Retrieved March 8, 2015.

http://www.mathworks.com/matlabcentral/fileexchange/15161­plotcube

3. Malasri, Siripong (2011) Shelf Space Optimization Using a Genetic Algorithm. Retrieved

March 20, 2015.

http://www.maesc.org/maesc11/Papers/Malasri_Segui_ShelfSpace

OptimizationUsingAGeneticAlgorithm_paper.pdf

11