SEMINAR REPORT ON TRAVELLING SALESMAN PROBLEM USING GENETIC ALGORITHM

SUBMITTED BY: Gaurav Mehta (284008)

SUBMITTED TO: MS. SHEFALI SINGHAL MRS. ANAMIKA GOEL

CAREER INSTITUTE OF TECHNOLOGY AND MANAGEMENT Aravali Hills, Sector-43, Faridabad(Haryana)

Page1

CHAPTER 1 INTRODUCTION

1.1 ABSTRACT The traveling-salesman problem is one of the classical ARTIFICIAL INTELLIGENCE problems. No current algorithms are available which can solve these problems in polynomial time, that is, the number of steps grows as a polynomial according to the size of the input. The traveling-salesman problem involves a salesman who must make a tour of a number of cities using the shortest path available. For each number of cities n, the number of paths which must be explored is n!, causing this problem to grow exponentially rather than as a polynomial. Three separate algorithms are examined. These are an iterative algorithm, a recursive algorithm, and a branch and bound algorithm. The iterative algorithm generates tours as the permutations of the first n - 1 integers (where n is the number of cities). The recursive algorithm begins with a subtour consisting of the starting city and uses a recursive subroutine to build all tours. The branch and bound algorithm builds a tree which represents tours. Each node of the tree has an associated bound, and when the bound of a node becomes larger than the cost of the best tour found so far, that node is no longer eligible for exploration. This pruning process allows this algorithm to delay exponential growth longer than the other two algorithms do. Two algorithms which develop near optimal solutions are also examined. But most important of all is the GENETIC ALGORITHM , which supports comparatively faster and optimal solution. GENETIC ALGORITHM (GA) is an optimization technique for searching very large spaces that models the role of the genetic material in living organisms. A small population of individual exemplars can search a large space because they contain schemata, useful substructures that can be potentially combined to make better individuals. Formal studies of competing schemata show that the best policy for replicating them is to increase them exponentially according to their relative fitness. This turns out to be the policy used by genetic algorithms. Fitness is determined by examining a large number of individual fitness cases. This process can be very efficient if the fittness cases also evolve by their own GAs.

Page1

1.2 ABOUT THE PROJECT Travelling salesman Problem is a problem intended for finding the optimal solution when a travelling salesman has to traverse across all the cities and return back to the starting point. Initially ,if he has to travel across 30 cities ,the number of proposition can be 2 raise to the poer 30,but with the help of genetic algorithm the number of proposition can be reduced to some extent and the computation is very fast. History : The origins of the travelling salesman problem are unclear. A handbook for travelling salesmen from 1832 mentions the problem and includes example tours through Germany and Switzerland, but contains no mathematical treatment. The travelling salesman problem was defined in the 1800s by the Irish mathematician W. R. Hamilton and by the British mathematician Thomas Kirkman. Hamiltons Icosian Game was a recreational puzzle based on finding a Hamiltonian cycle.[2] The general form of the TSP appears to have been first studied by mathematicians during the 1930s in Vienna and at Harvard, notably by Karl Menger, who defines the problem, considers the obvious brute-force algorithm, and observes the non-optimality of the nearest neighbour heuristic: Hassler Whitney at Princeton University introduced the name travelling salesman problem soon after. In the 1950s and 1960s, the problem became increasingly popular in scientific circles in Europe and the USA. Notable contributions were made by George Dantzig, Delbert Ray Fulkerson and Selmer M. Johnson at the RAND Corporation in Santa Monica, who expressed the problem as an integer linear programand developed the cutting plane method for its solution. With these new methods they solved an instance with 49 cities to optimality by constructing a tour and proving that no other tour could be shorter.

Page1

Richard M. Karp showed in 1972 that the Hamiltonian cycle problem was NP-complete, which implies the Np-hardness of TSP. This supplied a mathematical explanation for the apparent computational difficulty of finding optimal tours. Great progress was made in the late 1970s and 1980, when Grtschel, Padberg, Rinaldi and others managed to exactly solve instances with up to 2392 cities, using cutting planes and branch n bound. In the 1990s, Applegate, Bixby and Cook developed the program Concorde that has been used in many recent record solutions. Gerhard Reinelt published the TSPLIB in 1991, a collection of benchmark instances of varying difficulty, which has been used by many research groups for comparing results. In 2005, Cook and others computed an optimal tour through a 33,810-city instance given by a microchip layout problem, currently the largest solved TSPLIB instance. For many other instances with millions of cities, solutions can be found that are guaranteed to be within 1% of an optimal tour.

Description: As a graph problem TSP can be modelled as an undirected weighted graph, such that cities are the graph's vertices, paths are the graph's edges, and a path's distance is the edge's length. It is a minimization problem starting and finishing at a specified vertex after having visited each other vertex exactly once. Often, the model is acomplete graph (i.e. each pair of vertices is connected by an edge). If no path exists between two cities, adding an arbitrarily long edge will complete the graph without affecting the optimal tour. Asymmetric and symmetric In the symmetric TSP, the distance between two cities is the same in each opposite direction, forming an undirected graph. This symmetry halves the number of possible solutions. In the asymmetric TSP, paths may not exist in both directions or the distances might be different, forming a directed graph. Traffic collisions, one-way streets, and airfares for cities with different departure and arrival fees are examples of how this symmetry could break down.

1.3 PROJECT MOTIVATION

Page1

The current project TRAVELLING SALESMAN PROBLEM USING GENETIC ALGORITHM is stand alone application which stores the cities in an xml list .The Cities are encoded in form Binary Info as a Genetic Information and then the according to it the cities are traversed.The traversal follows the law of Genetic Algorithm for the computation.

1.4 AIMS AND OBJECTIVES 1) To find an optimal solution for n number of cities. 2) To traverse across all the cities quickly. 3) To come back to intial position by travelling across all cities once.

Page1

CHAPTER 2 SYSTEM ANALYSIS

2.1 INTRODUCTION System analysis is the process of gathering and interpreting facts, diagnosing problems and sings the information to recommend improvements on the system. System analysis is the problem solving activity that requires intensive communication between the system users and system developers. System analysis or study is a important phase of any system development process. Assuming that a new system is to be developed, the next phase is system analysis. Analysis involved a detailed study of the current system, leading to specifications of a new system. Analysis is a detailed study of various operations performed by a system and their relationships within and outside the system. During analysis, data are collected on the available files, decision points and transactions handled by the present system. Interviews, on-site observation and questionnaire are the tools used for system analysis. Using the following steps it becomes easy to draw the exact boundary of the new system under consideration:

Keeping in view the problems and new requirements Workout the pros and cons including new areas of the system

All procedures, requirements must be analysed and documented in the form of detailed data flow diagrams (DFDs), data dictionary, logical data structures and miniature specifications. System Analysis also includes sub-dividing of complex process involving the entire system, identification of data store and manual processes. The main points to be discussed in system analysis are: Page1

Specification of what the new system is to accomplish based on the user requirements. Functional hierarchy showing the functions to be performed by the new system and their relationship with each other.

Function network which are similar to function hierarchy but they highlight the those functions which are common to more than one procedure. List of attributes of the entities - these are the data items which need to be held about each entity (record)

The software requirement specification is an analysis task. The function and performance allocated to software as part of system engineering are refined by establishing a complete information description, a detailed functional description, a representation of system behavior, an indication of performance requirement and design constraints, appropriate validation criteria, and other information is required. Software requirement specification states the goal and objectives of the software, describing it in the context of computer-based system. In software requirement specification provides a detailed description of the problem that the software must be solve. Information content flow and structure are documented. Validation Criteria is probably the most important and ironically, the most often neglected section of the software requirement specification. How do we recognize a successful implementation? What classes of tests must be conducted to validate function, performance, and constraints? We neglect this section because completing it demands a through understanding of software requirement - something that we often do not have at this stage. Finally the specification includes a bibliography and appendix. The bibliography contains references to all documents that are related to the software. These include other software engineering documentation, technical references, vendor literature and standards. The appendix contains information that supplements the specifications. Tabular data, detailed description of algorithms, chart, graphs and other materials are presented as appendixes. The requirement gathering process is intensified and focused specifically on software. To understand the nature of programs to be built, the software engineers figure out required functions, behavior, performance, and interface. Requirement for both the system and the software are documented and reviewed with the customer.

Page1

2.2 GENETIC ALGORITHM

Genetic algorithms are an optimization technique based on natural evolution. They include the survival of the fittest idea into a search algorithm which provides a method of searching which does not need to explore every possible solution in the feasible region to obtain a good result. Genetic algorithms are based on the natural process of evolution. In nature, the fittest individuals are most likely to survive and mate; therefore the next generation should be fitter and healthier because they were bred from healthy parents. This same idea is applied to a problem by first guessing solutions and then combining the fittest solutions to create a new generation of solutions which should be better than the previous generation.

Page1

2.3 SOFTWARE REQUIREMENTS Software and human interfaces are described for external system element and internal system elements. A description of each function required to solve the problem is presented in the functional description. A processing narrative is provided for each function, design, constraints are stated and justified, performance characteristics are stated, and one or more diagrams are included to graphically represent the overall structure of the software and interplay among software functions and other system element. The specification examines the operations of the software as a consequence of external events and internally generated control characteristics. Programming Language: o ASP.NET using C# (Through the .NET Framework) o SQL(Structured Query Language) Data Store: o Microsoft SQL Server

Page1

Integrated Development Environment: o Microsoft Visual Studio 2008 Professional o Adobe Macromedia Flash

2.5 HARDWARE REQUIREMENTS Processor: Core Duo System Bus: 32 BIT Ram: 512MB HDD: 100GB

CHAPTER 3 IMPLEMENTATION

Page1

3.1 ATTRIBUTES USED. A genetic algorithm can be used to find a solution is much less time. Although it might not find the best solution, it can find a near perfect solution for a 100 city tour in less than a minute. There are a couple of basic steps to solving the traveling salesman problem using a GA. First, create a group of many random tours in what is called a population. This algorithm uses a greedy initial propulation that gives preference to linking cities that are close to each other. Second, pick 2 of the better (shorter) tours parents in the population and combine them to make 2 new child tours. Hopefully, these children tour will be better than either parent. A small percentage of the time, the child tours are mutated. This is done to prevent all tours in the population from looking identical.

The new child tours are inserted into the population replacing two of the longer tours. The size of the population remains the same. New children tours are repeatedly created until the desired goal is reached. As the name implies, Genetic Algorithms mimic nature and evolution using the principles of Survival of the Fittest.

3.2 SELECTION ISSUES

Fitness Function
Fitness functions are applied after evaluation and before parent selection. An equivalent could also be used when removing individuals from the population but this is not a common feature. Evaluations of all individuals in the population must be presented to the fitness function so that comparisons can be made. One possibility is to in effect reevaluate each individual, assigning them this new value, and then carry to on as normal. Although easier to implement than other schemes this was rejected because it would destroy the initial evaluation which may be required again and could be expensive to calculate. One solution is a wrapper around the Population class. A fitness object is passed into the genetic model and is then be attached to a given population. When attached the object calculates an associated fitness score once for each individual. To obtain fitness values a fitness iterator is created which moves through the population returning individuals and their fitnesses. A separate iterator is required so that multiple scans of the population can progress at the same time. This created a small problem, The Blues does not need a fitness function but must have one because of the decision to apply the same methods to all genetic algorithms. Along with standard fitness function - Windowing, Linear Normalisation, and so on - another, the Unity Fitness class had to be introduced. For each individual in the population this returns the same value as found during evaluation. Null operations such as this are often not noticed within a system until a rigorous examination is made. Parent Selector From a fitness capped population individuals must be selected for reproduction. The obvious approach is an abstract Selector object and a number of concrete classes representing the different ways of choosing individuals. Common examples of selection techniques are best, random, and roulette wheel. The consistent approach to genetic algorithms required by the toolkit means others classes are needed. Some particular genetic algorithm prefer low values to high values. Normally one would change the evaluation function to invert values but in preference to that other selectors can be used lowering the burden on the algorithm's implementor. For example an Anti-roulette Wheel Selector returns individuals with a probability inversely proportional to its evaluation. If this class replaced the Roulette Wheel Selector in The Blues then black would become the preferred colour. Implementing selectors as objects also gives some speed advantages. When attached to a population any necessary calculations to make the selection can be done once and only once. For

Page1

example in the instance of a best individual selector one single search for this individual is made and the result can then be recorded. Any future calls to the selector will produce the same individual instantly. Individual Creator Creator class combines both initialisation and reproduction. Original designs had included two separate class but these were merged in an effort to reduce the complexity of the toolkit. Both perform similar jobs, the production of new individuals, and so have similar requirements. Initialisation at the start of a genetic algorithm in the standard case does not normally require parent individuals to draw on. Some genetic algorithms start with a population of specialised individuals who have been generated in other genetic algorithms. Initialisation becomes a matter of cloning old individuals into the new population. Equally, although reproduction normally involves parents, some algorithms may occasionally introduce completely new individuals to keep up genetic diversity. Given that several reproduction operators are used in each genetic algorithm a mechanism must exist to choose between them. One possibility was to pass in a set of reproduction operators for each run of the genetic algorithm. Associated with each is a weight determining the probability of that operator being chosen. A more advanced technique categorises reproduction operators as to whether or not they are combined operators. That is whether they just mutate or whether they mutate then crossover individuals. Repair algorithms can also be implemented as combination operators. First the normal reproduction operator is applied and then the resultant individual is corrected of any defects, converted back into a legal representation. This technique was chosen and implemented using a tree structure. A single combined reproduction operator is passed into the Model which would execute the appropriate leaf operators. Shown in Figure 8 are special And, Or, and Xor operators which form internal nodes. This reproduction is one but not both of (both Crossover and Mutate) or (either Crossover or Mutate or both). Both and Xor class hold weights to determine the probability of each branch of the tree being chosen.

Some implementation issues have to be resolved. The problem of getting information from the selection operator to one or more reproduction leaves. One solution was to give each operator its own selector during initialisation, some attached to the population through the fitness class and others attached to sibling reproduction operators. Figure 9 shows selectors as arrows pointing towards their source. The population class is represented by small grey circles. Such a design would treat all creation events evenly whether they draw from the old population or another operator. Each stage would have to create complete individuals ready to pass on to another operator and this would slow the algorithm. Also the ancestry of an individual might get a little chaotic with some parents never existing in any population. The final solution was for the reproduction tree to be informed of its selector and this information propagated down the tree to all reproduction operators who required it. During a creation event control was provided through the combination operators. The And operator will have to pull individuals from the selector and pass them first to its left hand operator and receiving solution

Page1

representations but not individuals, these bare representations are then passed to the right hand operator, changed and returned before begin packaged as individuals. The Xor operator can determine the relevant sub-tree and pass control down. The Or operator must decide to use either one or both sub-trees and can then act like an Xor or And operator respectively. Several methods are required to implement this technique. create: Creator, Population, size create: Creator, History, Population, size parents: Creator > number breed: Creator, [Representation], Representation > succeed When the Model object require more individuals the create method is called. Two variants were provided, one to keep track of ancestry, the other not. Combination operators use the parents method to plan their strategy. Finally thebreed method produces new representations which could then be wrapped up as individuals after more modification. A question never adequately answered during the design of the toolkit is how many individuals should a crossover produce. Classic genetic algorithms set the answer at two, or for some of the more complex crossover, a larger but fixed number. Creating multiple individuals did not mesh with the toolkit's generality. When asking for a single individual a crossover might be selected from the tree and that would produce two or more individuals instead. The toolkit could not know how many to expect and would not know what to do with any surplus. The chosen solution was to only ever create a single individual for any reproduction operator. More operations might have to be performed but there can be no confusion about the number of individuals produced and no time wasted on creating surplus individuals.

3.3 WORKING(INTERNAL)

The two complex issues with using a Genetic Algorithm to solve the Traveling Salesman Problem are the encoding of the tour and the crossover algorithm that is used to combine the two parent tours to make the child tours. In a standard Genetic Algorithm, the encoding is a simple sequence of numbers and Crossover is performed by picking a random point in the parent's sequences and switching every number in the sequence after that point. In this example, the crossover point is between the 3rd and 4th item in the list. To create the children, every item in the parent's sequence after the crossover point is swapped. Parent 1 Parent 2 Child 1 Child 1 FAB|ECGD DEA|CGBF DEA|ECGD Page1 FAB|CGBF

The difficulty with the Traveling Salesman Problem is that every city can only be used once in a tour. If the letters in the above example represented cities, this child tours created by this crossover operation would be invalid. Child 1 goes to city F & B twice, and never goes to cities D or E. The encoding cannot simply be the list of cities in the order they are traveled. Other encoding methods have been created that solve the crossover problem. Although these methods will not create invalid tours, they do not take into account the fact that the tour "A B C D E F G" is the same as "G F E D C B A". To solve the problem properly the crossover algorithm will have to get much more complicated. My solution stores the links in both directions for each tour. In the above tour example, Parent 1 would be stored as: City A B C D E F First Connection F A E G B D Second Connection B E G F C A

G C D The crossover operation is more complicated than combining 2 strings. The crossover will take every link that exists in both parents and place those links in both children. Then, for Child 1 it alternates between taking links that appear in Parent 2 and then Parent 1. For Child 2, it alternates between Parent 2 and Parent 1 taking a different set of links. For either child, there is a chance that a link could create an invalid tour where instead of a single path in the tour there are several disconnected paths. These links must be rejected. To fill in the remaining missing links, cities are chosen at random. Since the crossover is not completely random, this is considered a greedy crossover. Eventually, this GA would make every solution look identical. This is not ideal. Once every tour in the population is identical, the GA will not be able to find a better solution. There are two ways around this. The first is to use a very large initial population so that it takes the GA longer to make all of the solutions the same. The second method is mutation, where some child tours are randomly altered to produce a new unique tour. This Genetic Algorithm also uses a greedy initial population. The city links in the initial tours are not completely random. The GA will prefer to make links between cities that are close to each other. This is not done 100% of the time, becuase that would cause every tour in the initial population to be very similar. Page1

3.4 WORKING (EXTERNAL) There are 6 parameters to control the operation of the Genetic Algorithm: Population Size - The population size is the initial number of random tours that are created when the algorithm starts. A large population takes longer to find a result. A smaller population increases the chance that every tour in the population will eventually look the same. This increases the chance that the best solution will not be found. Neighborhood / Group Size - Each generation, this number of tours are randomly chosen from the population. The best 2 tours are the parents. The worst 2 tours get replaced by the children. For group size, a high number will increase the likelyhood that the really good tours will be selected as parents, but it will also cause many tours to never be used as parents. A large group size will cause the algorithm to run faster, but it might not find the best solution. Mutation % - The percentage that each child after crossover will undergo mutation When a tour is mutated, one of the cities is randomly moved from one point in the tour to another. # Nearby Cities - As part of a greedy initial population, the GA will prefer to link cities that are close to each other to make the initial tours. When creating the initial population this is the number of cities that are considered to be close. Nearby City Odds % - This is the percent chance that any one link in a random tour in the initial population will prefer to use a nearby city instead of a completely random city. If the GA chooses to use a nearby city, then there is an equally random chance that it will be any one of the cities from the previous parameter. Maximum Generations - How many crossovers are run before the algorithm is terminated. The other options that can be configured are (note: these are only available in the downloadable version): Random Seed - This is the seed for the random number generator. By having a fixed instead of a random seed, you can duplicate previous results as long as all other parameters are the same. This is very helpful when looking for errors in the algorithm. City List - The downloadable version allows you to import city lists from XML files. Again, when debugging problems it is useful to be able to run the algorithm with the same exact parameters.

Page1

3.5 MODULES USED 1)CITIES.CS It stores the information about the number of cities present for the traversal. 2)CITY.CS It stores the information about the current city ,thus according to this the next child i.e city would be decided by fitness function. 3)POPULATION.CS It stores the random number of tours when the algorithm starts.

4)TSPFORM.CS It is how tsp form is implemented. 5)TOUR.CS It is basically used to store the current tour so that it could be compared with the next path according to fitness function..If new tour is better than it is chosen else the previous one is retained. 6)PROGRAM.CS It is created to provide the controls to the buttons such that they peform their function accordingly.

CHAPTER-4 ARCHITECTURE
4.1 INFORMATION FLOW

Genetic algorithms have a great many variations but also share common points. All have the common features of initialisation, evaluation, populations, and reproduction. From here that the design of the generic toolkit was started by considering the information pathways of the algorithm. However, this is insufficient because certain specialisations are not described in such a model. In particular there were three areas of deficiency. A large group of genetic algorithms use fitness functions to set up a more competitive environment. Most genetic algorithm make a considered opinion on whether to finish. Finally some genetic algorithms monitor their changing populations over time for historical tracing or additional processing, these are all specifically mentioned in the statement of requirements. Taking all these aspects into account produced Figure 6 which shows information steps within a generic genetic algorithm and the information flow between steps which typically consist of potential problem solutions. Those steps dealing with the three aspects which are not common to all algorithms are shown in grey.

Page1

Information flow

From the beginning of the project the intention had been to produce an object-oriented toolkit. Such a model is well suited to the desired extensible toolkit. Abstract classes would provide the toolkit and users inherit concrete classes for use in a particular genetic algorithm. This facility would also facilitate the construction of the toolkit enabling the range of services to be slowly expanded.Primary in toolkit design was the notion of flexibility and the speed at which a new algorithm could be assembled. Even so this had to be balanced against implementations which would take an unacceptably long time to run. Several genetic algorithms suggested minor variations which did not fit in with the majority of other algorithms. For example the elitist breeding technique is an extension of the standard generational technique. No other similar behaviours are mentioned in the literature and so the toolkit would have to implement elitism separately and either flag if active or not for a particular algorithm. Such behaviour is contrary to the generic ideal and slows down many algorithms for benefit a few.Fortunately a clue to the solution is already described, Lawrence Davis (1991). Two stages from the standard genetic model, the deletion of old individuals and insertion of new individuals, are often placed together. This suggested consolidating these procedures into a single object, one to do both jobs. A Model object would also take over most other stages of the genetic algorithm, its exact behaviour depending on the parameters such as reproduction operators but also on that model's particular make up. Page1

4.2 CLASS DEPENDECY

Class dependencies
It shows final choice of classes for the toolkit and the dependencies between them. Each arrow represents one class's knowledge about another. Around the diagram is a circle, this is just a combination of several dependency arrows. As can be seen the Model object has direct control over almost all other classes within the toolkit. Several objects have appeared in the diagram which do not seem to have any correspondence to the information flow diagram. Random is a pseudo-random number generator to provide for the probabilities needed by a genetic algorithm. By using a single controllable generator for the algorithm experiments can be replicated. Simply by storing the initial random number seed and the parameters used by the genetic algorithm, the same results may be obtained again and again. If real or arbitrary random numbers were used every individual would have to be recorded and traced to provide the same service. Representation is a abstract holding place for a single problem solution. Concrete examples of this class include binary vectors, ordered lists of integers, or 3D matrices. With all different representations packaged in the same way they may be dealt with equally by most of the toolkit. Only functions which depend on specific representations such as evaluation and reproduction operators need separate them.

Page1

Evaluation is apparently only a function and does not need object status. Simple evaluations can indeed be calculated directly from the representation but many need auxiliary information. An object provides storage space for such details, an example of such is shown in Chapter 5. Individual is the encapsulation of a Representation. Each individual is uniquely identifiable not only within a single generation but within all generations in a particular algorithm. Even individuals with identical representations may be differentiated. Tracking the development of individuals over time is impossible without this. Population provides a simple set for storing individuals. Ending makes the decision on whether or not another cycle of the genetic algorithm should be made. Several concrete class are available including ones based on time, generation count, and target evaluations. Complex combinations can be formed by joining simple ending objects with And, Or, or Xor operators also implemented as Ending objects.

Page1

CHAPTER 5 SCREENSHOTS

HOME PAGE:

Page1

CITIES CAN BE ENTED JUST BY CLICKING THE MOUSE AT THAT POSITION..

Page1

CLICKING START:

ON THE WAY OF OPTIMAL SOLUTION

Page1

FINAL RESULT

Page1

CITIES FROM THE DATABASE COULD BE LOADED

Page1

Page1

MAPS CAN BE LOADED FROM THE DATABASE

Page1

Page1

DISTINTICTION AND DESCRIPTION ABOUT THE PLACE

Page1

Page1

Page1

Page1

Page1

Page1

CHAPTER 6 APPLICATIONS

Much of the work on the TSP is motivated by its use as a platform for the study of general methods that can be applied to a wide range of discrete optimization problems. This is not to say, however, that the TSP does not find applications in many fields. Indeed, the numerous direct applications of the TSP bring life to the research area and help to direct future work. The TSP naturally arises as a subproblem in many transportation and logistics applications, for example the problem of arranging school bus routes to pick up the children in a school district. This bus application is of important historical significance to the TSP, since it provided motivation for Merrill Flood, one of the pioneers of TSP research in the 1940s. A second TSP application from the 1940s involved the transportation of farming equipment from one location to another to test soil, leading to mathematical studies in Bengal by P. C. Mahalanobis and in Iowa by R. J. Jessen. More recent applications involve the scheduling of service calls at cable firms, the delivery of meals to homebound persons, the scheduling of stacker cranes in warehouses, the routing of trucks for parcel post pickup, and a host of others. Although transportation applications are the most natural setting for the TSP, the simplicity of the model has led to many interesting applications in other areas. A classic example is the scheduling of a machine to drill holes in a circuit board or other object. In this case the holes to be drilled are the cities, and the cost of travel is the time it takes to move the drill head from one hole to the next. The technology for drilling varies from one industry to another, but whenever the travel time of the drilling device is a significant portion of the overall manufacturing process then the TSP can play a role in reducing costs. Its application are as follows. 1)Genome 2)Starlight 3)Scan Chains 4)DNA 5)Sonet 6)Power Cables Page1 7)Airport Tours

6.1 GENOME
Researchers at the National Institute of Health have used Concorde's TSP solver to construct radiation hybrid maps as part of their ongoing work in genome sequencing. The TSP provides a way to integrate local maps into a single radiation hybrid map for a genome; the cities are the local maps and the cost of travel is a measure of the likelihood that one local map immediately follows another. A report on the work is given in the paper A Fast and Scalable Radiation Hybrid Map Construction and Integration Strategy", by R. Agarwala, D.L. Applegate, D. Maglott, G.D. Schuler, and A.A. Schaffler. This application of the TSP has been adopted by a group in France developing a map of the mouse genone. The mouse work is decribed in "A Radiation Hybrid Transcript May of the Mouse Genome"nature genetic 29 (2001), pages 194--200.

6.2 STARLIGHT
A team of engineers at Hernandez Engineering in Houston and at Brigham Young University have experimented with using Chained Lin-Kerninghan to optimize the sequence of celestial objects to be imaged in a proposed NASA Starlight space interferometer program. The goal of the study it to minimize the use of fuel in targeting and imaging maneuvers for the pair of satellites involved in the mission (the cities in the TSP are the celestial objects to be imaged, and the cost of travel is the amount of fuel needed to reposition the two satellites from one image to the next). A report of the work is given in the paper "Fuel Saving Strategies for Separated Spacecraft Interferometry".

6.3 SCAN CHAINS

A semi-conductor manufacturer has used Concorde's implementation of the Chained LinKernighan heuristic in experiments to optimize scan chains in integrated circuits. Scan chains are routes included on a chip for testing purposes and it is useful to minimize their length for both timing and power reasons.

6.4 DNA
A group at AT&T used Concorde to compute DNA sequences in a genetic engineering research project. In the application, a collection of DNA strings, each of length k, were embedded in one universal string (that is, each of the target strings is contained as a substring in the universal string), with the goal of minimizing the length of the universal string. The cities of the TSP are the target strings, and the cost of travel is k minus the maximum overlap of the corresponding strings.

6.5 SONET

Page1

An early version of Concorde's tour finding procedures was used in a tool for designing fiber optical networks at Bell Communications Research (now Telcordia). The TSP aspect of the problem arises in the routing of sonet rings, which provide communications links through a set of sites organized in a ring. The ring structure provides a backup mechanism in case of a link failure, since traffic can be rerouted in the opposite direction on the ring.

6.6 POWER CABLES

Modules from Concorde were used to locate cables to deliver power to electronic devices associated with fiber optic connections to homes. Some general aspects of this problem area are discussed in the paper powering the last mile".

6.7 AIRPORT TOURS

Concorde is currently being incorporated into the world wide airport path finder web site to find shortest routes through selections of airports in the world. The author of the site writes that users of the path-finding tools are equally split between real pilots and those using flight simulators.

Page1