0

I'm playing around with the travelling salesman example provided with GLPK, and trying to get a feel for what problem size I can reasonably expect to solve. I've managed to solve a 50 node graph, but 100 nodes doesn't seem to be converging in a reasonable timescale (30 minutes or so on modern hardware).

GLPK has lots of options for the MIP solver. I've tried various combinations but I'm not at all clear what options might help. This page has some discussion but is somewhat out of date and the advice is rather general.

Is it reasonable to expect GLPK to solve a 100 node tour or greater in a practical time frame (say, less than 4 hours)? When does the problem size become intractable? Are any of the many command-line options likely to help?

ire_and_curses
  • 68,372
  • 23
  • 116
  • 141

2 Answers2

1

Are any of the many command-line options likely to help?

The tspsol command line applicaton (based on the GLPK C library) or the C API in glptsp.h are tailor-made for solving TSP.

Is it reasonable to expect GLPK to solve a 100 node tour or greater in a practical time frame (say, less than 4 hours)? When does the problem size become intractable?

My guess is that it also greatly depends on the problem instance as well. If you look into the C code, you will see that heuristics are used to generate an initial tour. How well a heuristic works, well...

I assume you know that the TSP is famous for being difficult to solve, see computational complexity.

ire_and_curses
  • 68,372
  • 23
  • 116
  • 141
Ali
  • 56,466
  • 29
  • 168
  • 265
  • Oh, I know all about the complexity, as well as many of the possible heuristics. I have implemented simple heuristics in Python which can solve instances up to a few thousand cities. My question is whether GLPK, being a pure LP + MIP solver, can reasonably be expected to solve a (Euclidean) TSP of reasonable size. In my tests, it seems the mixed integer solver takes a very long time to converge. I wonder in particular whether it's possible to improve this aspect, perhaps with command line options. Or perhaps it is the formulation of the example I linked to which is at fault? – ire_and_curses Aug 25 '13 at 20:36
  • @ire_and_curses If you want to see how you can improve GLPK in this aspect then see the code for tspsol and glptsp.c as I write it in may answer. In the end, the "pure LP+MIP" solver will be called, just in a way that is hopefully the best for TSPs. – Ali Aug 25 '13 at 20:40
  • +1: Your answer is helpful, although not complete for what I'm asking. I've looked through the code for `tspsol`. It's written by the GLPK author, which provides some evidence that the solver alone cannot make significant progress against this problem. I also note that this is an example, rather than a custom solution. It uses basic branch and bound. See the comment at the top: *Note that this program is only an illustrative example. It is not a state-of-the-art code, therefore only TSP instances of small size (perhaps not more than 100 cities) can be solved using this code.* – ire_and_curses Aug 25 '13 at 20:56
  • @ire_and_curses So, you have found the answer in the code after all, haven't you? Well, I can't blame the developer, I wouldn't want to put more effort into this specific application either, considering that better alternatives are available. May I ask: Why are you so interested in applying a pure LP + MIP solver to this problem? – Ali Aug 25 '13 at 21:52
  • @ire_and_curses You know that GLPK is not the best choice when it comes to MIP; check [this comparison](http://scip.zib.de/) for alternatives. – Ali Aug 25 '13 at 21:56
  • Let me try and phrase it a different way. If GLPK can't natively (i.e. via a MathProg formulation) solve tours of 100 cities, then I'm interested in understanding why. In particular, is this a limitation of GLPK, or constraint solvers in general? According to my understanding of TSP, B+B plus cutting plane methods are a good approach. GLPK implements cutting planes via command line options. In practice however they seem to have limited effectiveness. – ire_and_curses Aug 25 '13 at 22:23
  • The bigger picture here is that I am investigating the effectiveness of LP + MIP against a range of NP-hard problems. TSP is just one of them. In particular, I am trying to build an understanding of which problems have structure amenable to an approach like GLPK, and why. Thanks for the benchmark link - I may compare some other solvers. Unfortunately, each solver takes time to understand and learn its language, and for various reasons I am commited to using GLPK in a real-world application. – ire_and_curses Aug 25 '13 at 22:27
  • @ire_and_curses Please drop me a note when you are done with your investigation (I mean the bigger picture), I am curious about the outcome! Best of luck! – Ali Aug 25 '13 at 22:40
1

I was able to solve eil51 in 2 seconds and rat99 in about 50 seconds by starting with a relaxation of the TSP and then eliminating sub-tours until a feasible solution is found. Doing a better modelling is going to achieve more than fiddling with the solver options. GLPK should be able to deal with bigger instances if the modelling is good enough. eil51 and rat99 are instances documented on TSPLIB.

I recommend reading some material on tsp modelling, there are a lot of articles and books out there. A nice starting point maybe 'Applied Integer Programming' by Der-San Chen et al.

ire_and_curses
  • 68,372
  • 23
  • 116
  • 141
Granada
  • 363
  • 1
  • 3
  • 7