From robinlh at us.ibm.com Wed Jan 8 16:51:46 2003 From: robinlh at us.ibm.com (Robin Lougee-Heimer) Date: Wed Nov 24 00:04:10 2004 Subject: [Coin-contest] announcing the COIN-OR Open-Source Coding Contest Message-ID: The COIN-OR Open-Source Coding Contest: Win an IBM ThinkPad. At the 2000 International Symposium for Mathematical Programming (ISMP), COIN-OR (http://www.coin-or.org) was launched by IBM Research with the goal of promoting "open-source" software for operations-research professionals. Our lofty mission was to explore an alternative means for developing, managing, and distributing OR software so that OR professionals could benefit from peer-reviewed, archived, openly-disseminated software (much in the same way we already benefit from theory). In November 2002, a milestone toward the project's long-term objectives was reached when the INFORMS board unanimously accepted a proposal to become the new host of the COIN-OR initiative. To celebrate, we're throwing a contest! Visit http://www.coin-or.org/contest.htm to find out how you can win an IBM ThinkPad. Prizes will be awarded August 2003 at the 2003 ISMP in Copenhagen, Denmark. ---------------------------------------------------------------------------------- Robin Lougee-Heimer IBM TJ Watson Research Center ph: 914-945-3032 fax: 914-945-3434 robinlh@us.ibm.com http://www.coin-or.org From BSKhoo at csupomona.edu Wed Jan 8 21:21:42 2003 From: BSKhoo at csupomona.edu (Khoo, Benjamin S.) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] Coding Contest Message-ID: Hi I just saw the announcement for the coding contest. I am just curious, the contest is only for C++? Is java a viable option? Regards, Ben ============================================ Benjamin Khoo PhD, MSIS, MSSwEngrg, BEngrg CLA Building 98 Room C3-13 Computer Information Systems Dept., College of Business Administration, California State Polytechnic University, Pomona, CA 91768 Telephone # (909) 869-2012 eMail: bskhoo@csupomona.edu or benson45us@yahoo.com URL: http://www.csupomona.edu/~bskhoo ============================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.coin-or.org/pipermail/coin-contest/attachments/20030108/b17c3809/attachment.htm From robinlh at us.ibm.com Mon Jan 13 14:15:01 2003 From: robinlh at us.ibm.com (Robin Lougee-Heimer) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] Coding Contest Message-ID: Java is not prohibited, but don't forget that the submissions will be evaluated based on performance. ---------------------------------------------------------------------------------- Robin Lougee-Heimer IBM TJ Watson Research Center ph: 914-945-3032 fax: 914-945-3434 robinlh@us.ibm.com http://www.coin-or.org "Khoo, Benjamin S." @www-124.southbury.usf.ibm.com on 01/08/2003 09:21:42 PM Sent by: coin-contest-admin@www-124.southbury.usf.ibm.com To: "'coin-contest@www-124.ibm.com'" cc: Subject: [Coin-contest] Coding Contest Hi I just saw the announcement for the coding contest. I am just curious, the contest is only for C++? Is java a viable option? Regards, Ben ============================================ Benjamin Khoo PhD, MSIS, MSSwEngrg, BEngrg CLA Building 98 Room C3-13 Computer Information Systems Dept., College of Business Administration, California State Polytechnic University, Pomona, CA 91768 Telephone # (909) 869-2012 eMail: bskhoo@csupomona.edu or ????????? benson45us@yahoo.com URL: http://www.csupomona.edu/~bskhoo ============================================ From jjforre at us.ibm.com Wed Jan 22 14:31:13 2003 From: jjforre at us.ibm.com (John J Forrest) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] State of Sbb Message-ID: I think I have now got Sbb in a good enough state for people to start looking at it. I have put into cvs: a) My current competition driver i.e. the one people have to beat. There will be improvements e.g. hopefully the cut generators will be better deployed and there will be a first attempt at an integer presolve, but it gives a reasonable idea as to the sort of code it will be. The driver is sample2.cpp in Sbb/Samples together with various files starting Sbb which are examples of how to modify search strategy and add a new heuristic. Adding cut generators is just a matter of keeping to Cgl cut generator methods. b) I have put a directory miplib3 in Samples which has miplib.cat and 59 problems. c) There is a trivial script "runtimes" in Samples which runs some or all of set. A time limit in minutes may be passed in. At present 44 out of the 59 are uncommented so they will run. These 44 run in less than 30 minutes with a total of just over 2 hours (1.7 ghz Pentium 4). A few more can be run by giving a longer time and/or tweaking parameters e.g. mod011, qiu. The version of Sbb (and associated Clp, Coin, Osi and Cgl) has been tagged in cvs with the tag sbb-0-60-0 to indicate Sbb version 0.60.0. Please comment where you think code needs extra explanations. John Forrest From nediakm at math.mcmaster.ca Fri Jan 24 16:13:04 2003 From: nediakm at math.mcmaster.ca (Mikhail Nediak) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] Problems running Sbb on miplib Message-ID: Dear COIN community, I am having some problems with running Sbb. Everything compiled and linked almost fine. I have not really changed anything in the makefiles, except that my "default" installation of Mandrake does not include readline and stuff, so I had to comment out corresponding lines (so that symbol READLINE is no longer defined). I could run sbb -unitTest without any problems. However, sbb -miplib produces this output: Testing some miplib stuff processing mps file: fixnet6 (1 out of 41) Coin0001I At line 22 NAME FIXNET6 Coin0001I At line 23 ROWS Coin0001I At line 503 COLUMNS Coin0001I At line 2620 RHS Coin0001I At line 2662 BOUNDS Coin0001I At line 3163 ENDATA Coin0002I Problem FIXNET6 has 478 rows, 878 columns and 1756 elements Coin0008I FIXNET6 read with 0 errors Clp0005I 0 Objective 0 Primal infeas 424.095 (81) Clp0005I 189 Objective 1200.88 Clp0000I Optimal - objective value 1200.88 Sbb0013I At root node, 136 cuts changed objective from 1200.88 to 3196.4 in 8 passes Sbb0014I Cut generator 0 (Unknown) - 6 row cuts (2 active), 0 column cuts - new frequency is 0 Sbb0014I Cut generator 1 (Unknown) - 134 row cuts (134 active), 0 column cuts - new frequency is 0 Sbb0014I Cut generator 2 (Unknown) - 0 row cuts (0 active), 0 column cuts - new frequency is 0 Segmentation fault Similar thing happens after making Sample1 and running, say testit miplib3/p0033 Except that in this case it crashes a bit later: ... Sbb0014I Cut generator 3 (Unknown) - 0 row cuts (0 active), 0 column cuts - new frequency is 0 Sbb0010I After 0 nodes, 1 on tree, 1e+50 best solution, best possible 3078.37 Floating exception What am I doing wrong? I am running Mandrake Linux 9.0 and g++ 3.2. The same thing happened on another computer running RedHat 7.3 and g++ 2.96. I will be very grateful for any suggestions. Thanks. Best regards, Mikhail Nediak From jjforre at us.ibm.com Sat Jan 25 15:58:37 2003 From: jjforre at us.ibm.com (John J Forrest) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] Problems running Sbb on miplib Message-ID: I have fixed some problems with the miplib test using sbb and/or Samples/sample1.cpp. sample2.cpp was okay, but I should have kept on checking the unit tests (always a good idea). John Forrest From jjforre at us.ibm.com Sun Jan 26 16:08:08 2003 From: jjforre at us.ibm.com (John J Forrest) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] Re: SBB In-Reply-To: Message-ID: John, As this may be of interest to others, I am posting my reply to coin-contest. The intent is that by the end of January - not later than 6pm EST February 7 the Sbb code will be functionally frozen. I may work on improving the speed of existing code (and fixing bugs), but not on the functionality. I will also be improving the documentation etc etc. If you have any concerns, please raise them. John Forrest John Dethridge cc: Subject: SBB 01/25/2003 10:57 PM Hello Mr. Forrest, I was wondering if you were planning on making any more changes to the SBB code before the end of March. It is hard to start working on the contest when anything we write might become redundant! Thanks, -John Dethridge From jjforre at us.ibm.com Mon Jan 27 16:06:33 2003 From: jjforre at us.ibm.com (John J Forrest) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] Wish list for OsiClp, questions on Sbb Message-ID: Mikhail Nediak asked some questions and I am answering on coin-contest. The original questions and answers are at end of this note. >I guess, there are really two types of issues that I care about. First >group is Osi/Clp. Ideally, I would like to have an extended >Osi interface to Clp (it is that OsiSimplexInterface that I and >Jonathan posted on coin-discuss a few month ago). In this case we could >test our complete pivot-based heuristic with all bells and whistles. >Osi way makes the heuristic implementation more general, since it would >work with any solver that supports the extended interface. For now, we had >this interface for CPLEX 7.x and Bob Vanderbei's SIMPO. Of course, I >would implement all these methods (or at least the most important ones) >myself, if I only had some guidance on how to approach this task. I am >attaching the interface's header to show what kind of methods >we had in mind. Most of these are perfectly implementable for CPLEX using >standard functions or the ones described in CPLEX's "Advanced Reference >Manual" (read "potentially non-portable to future versions" :-( ) Mikhail - I will try an add some code to the OsiClpSolverInterface for OsiSimplexInterface. I am tempted to include it in OsiSolverInterface base class and have the default be to abort if a function is called. That way you could easily get Cplex and Clp to work. It may take some time before I get round to it but it should be in by end of February. >On the other hand, if implementation of this extension is too tedious >and/or requires some serious modifications to Clp, we would even be >satisfied with regular Osi interface functionality. We could then test a >much simplified version of the heuristic. I would still care, however, if >it is possible to easily extract tableau info from Clp (in this case we >could also add and test some extra Cgl-style cut generators). If I do the above, the tableau information will be easily available. At present it can be extracted when using any solver by using CoinFactorization. To see how look at CglGomory.cpp and lines with ==== in them (just checked in). >In both cases, there are still some Sbb issues. For example, how often >are heuristics called in Sbb? From our experience, we had to look at the >gap of the current subproblem and its integrality relative to other >subproblems in the pool to save some time. Otherwise, too much effort is >wasted. This is an area which needs a lot of work. At present it is very crude. The user can say do every k nodes or if -1 then it checks every 100 nodes if any cuts are generated - anyway that's approximately what happens. >Second, what does the solver_ in the model of SbbHeuristic object >correspond to? Can I make sure that when a heuristic is called, it >contains the current subproblem with relaxation solved to optimality >(i.e., proper LP basis loaded)? Will all applicable cuts be "in"? >Third, will I be able to use some cut generators inside the heuristic (it >is really a heuristic branch-and-cut)? In SbbHeuristic model_->solver() gives the OsiSolverInterface pointer to current model (with cuts and optimal). The underlying solver will be same one set in main program. model_->continuousSolver() should give model with initial state. At present you can use cut generators in the heuristic but there is no way to pass these cuts back. If you were going to then the code should really be in as a cut generator? If you are going to modify model then clone the solver and modify that. Please keep the questions coming. John Forrest -------------------------------------------- > Mikhail, > > Sbb uses the Osi interface. I am at present working on a first version of > an integer presolve, which for the moment assumes that the user is actually > using clp as the solver. So I do a dynamic cast to clp and then use Clp's > presolve. I intend to enhance that presolve and also give it an osi > interface. > > However I think it valid to allow the casting to clp and then using clp > interface so my question to you is - do you want to do things at the Osi > level or Clp level. If at the Clp level I have more freedom. > > If it is at Clp level, what exactly do you want? For primal pivot in > choice or dual pivot out choice it is easy - for primal look at > ClpPrimalColumnPivot.hpp and ClpPrimalColumnDantzig.?pp (as that is > simplest). The corresponding pivot out/pivot in is more problematic but > anything can be done. > > So give me a hint. Also if you think your requests are of sufficient > generality, indicate that and I can post replies to coin-lpsolver and/or > coin-contest. > > John Forrest > > The original note from Mikhail. I am trying to test certain pivot-based heuristic with Sbb and the current interface does not seem sufficient. So I will have to, most likely, modify the place in the Sbb code where it is called (and, also the manner and the frequency of the calls). Could you please give me some suggestions on where I should start? Any advice is greatly appreciated. From jjforre at us.ibm.com Mon Jan 27 16:07:48 2003 From: jjforre at us.ibm.com (John J Forrest) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] Wish list for OsiClp, questions on Sbb Message-ID: Mikhail Nediak asked some questions and I am answering on coin-contest. The original questions and answers are at end of this note. >I guess, there are really two types of issues that I care about. First >group is Osi/Clp. Ideally, I would like to have an extended >Osi interface to Clp (it is that OsiSimplexInterface that I and >Jonathan posted on coin-discuss a few month ago). In this case we could >test our complete pivot-based heuristic with all bells and whistles. >Osi way makes the heuristic implementation more general, since it would >work with any solver that supports the extended interface. For now, we had >this interface for CPLEX 7.x and Bob Vanderbei's SIMPO. Of course, I >would implement all these methods (or at least the most important ones) >myself, if I only had some guidance on how to approach this task. I am >attaching the interface's header to show what kind of methods >we had in mind. Most of these are perfectly implementable for CPLEX using >standard functions or the ones described in CPLEX's "Advanced Reference >Manual" (read "potentially non-portable to future versions" :-( ) Mikhail - I will try an add some code to the OsiClpSolverInterface for OsiSimplexInterface. I am tempted to include it in OsiSolverInterface base class and have the default be to abort if a function is called. That way you could easily get Cplex and Clp to work. It may take some time before I get round to it but it should be in by end of February. >On the other hand, if implementation of this extension is too tedious >and/or requires some serious modifications to Clp, we would even be >satisfied with regular Osi interface functionality. We could then test a >much simplified version of the heuristic. I would still care, however, if >it is possible to easily extract tableau info from Clp (in this case we >could also add and test some extra Cgl-style cut generators). If I do the above, the tableau information will be easily available. At present it can be extracted when using any solver by using CoinFactorization. To see how look at CglGomory.cpp and lines with ==== in them (just checked in). >In both cases, there are still some Sbb issues. For example, how often >are heuristics called in Sbb? From our experience, we had to look at the >gap of the current subproblem and its integrality relative to other >subproblems in the pool to save some time. Otherwise, too much effort is >wasted. This is an area which needs a lot of work. At present it is very crude. The user can say do every k nodes or if -1 then it checks every 100 nodes if any cuts are generated - anyway that's approximately what happens. >Second, what does the solver_ in the model of SbbHeuristic object >correspond to? Can I make sure that when a heuristic is called, it >contains the current subproblem with relaxation solved to optimality >(i.e., proper LP basis loaded)? Will all applicable cuts be "in"? >Third, will I be able to use some cut generators inside the heuristic (it >is really a heuristic branch-and-cut)? In SbbHeuristic model_->solver() gives the OsiSolverInterface pointer to current model (with cuts and optimal). The underlying solver will be same one set in main program. model_->continuousSolver() should give model with initial state. At present you can use cut generators in the heuristic but there is no way to pass these cuts back. If you were going to then the code should really be in as a cut generator? If you are going to modify model then clone the solver and modify that. Please keep the questions coming. John Forrest -------------------------------------------- > Mikhail, > > Sbb uses the Osi interface. I am at present working on a first version of > an integer presolve, which for the moment assumes that the user is actually > using clp as the solver. So I do a dynamic cast to clp and then use Clp's > presolve. I intend to enhance that presolve and also give it an osi > interface. > > However I think it valid to allow the casting to clp and then using clp > interface so my question to you is - do you want to do things at the Osi > level or Clp level. If at the Clp level I have more freedom. > > If it is at Clp level, what exactly do you want? For primal pivot in > choice or dual pivot out choice it is easy - for primal look at > ClpPrimalColumnPivot.hpp and ClpPrimalColumnDantzig.?pp (as that is > simplest). The corresponding pivot out/pivot in is more problematic but > anything can be done. > > So give me a hint. Also if you think your requests are of sufficient > generality, indicate that and I can post replies to coin-lpsolver and/or > coin-contest. > > John Forrest > > The original note from Mikhail. I am trying to test certain pivot-based heuristic with Sbb and the current interface does not seem sufficient. So I will have to, most likely, modify the place in the Sbb code where it is called (and, also the manner and the frequency of the calls). Could you please give me some suggestions on where I should start? Any advice is greatly appreciated. From nediakm at math.mcmaster.ca Mon Jan 27 18:03:58 2003 From: nediakm at math.mcmaster.ca (Mikhail Nediak) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] Wish list for OsiClp, questions on Sbb In-Reply-To: Message-ID: > >I guess, there are really two types of issues that I care about. First > >group is Osi/Clp. Ideally, I would like to have an extended > >Osi interface to Clp (it is that OsiSimplexInterface that I and > >Jonathan posted on coin-discuss a few month ago). In this case we could > >test our complete pivot-based heuristic with all bells and whistles. > >Osi way makes the heuristic implementation more general, since it would > >work with any solver that supports the extended interface. For now, we had > >this interface for CPLEX 7.x and Bob Vanderbei's SIMPO. Of course, I > >would implement all these methods (or at least the most important ones) > >myself, if I only had some guidance on how to approach this task. I am > >attaching the interface's header to show what kind of methods > >we had in mind. Most of these are perfectly implementable for CPLEX using > >standard functions or the ones described in CPLEX's "Advanced Reference > >Manual" (read "potentially non-portable to future versions" :-( ) > > Mikhail - I will try an add some code to the OsiClpSolverInterface for > OsiSimplexInterface. I am tempted to include it in OsiSolverInterface base > class and have the default be to abort if a function is called. That way > you could easily get Cplex and Clp to work. It may take some time before I > get round to it but it should be in by end of February. I think it may be even better to have an interface class for a particular solver inherit from OsiSimplexInterface (which is purely virtual just like Java interfaces). In this case, one can do run-time checks whether it is actually supported using a pointer to OsiSolverInterface, e.g. OsiSolverInterface* sol = ...; ... OsiSimplexInterface* simplexSol = dynamic_cast(sol); if (simplexSol == NULL) { //... } else ... This will allow for a greater programming flesibility (and this is how we did it with CPLEX anyway). > > >On the other hand, if implementation of this extension is too tedious > >and/or requires some serious modifications to Clp, we would even be > >satisfied with regular Osi interface functionality. We could then test a > >much simplified version of the heuristic. I would still care, however, if > >it is possible to easily extract tableau info from Clp (in this case we > >could also add and test some extra Cgl-style cut generators). > > If I do the above, the tableau information will be easily available. At > present it can be extracted when using any solver by using > CoinFactorization. To see how look at CglGomory.cpp and lines with ==== in > them (just checked in). OK > >In both cases, there are still some Sbb issues. For example, how often > >are heuristics called in Sbb? From our experience, we had to look at the > >gap of the current subproblem and its integrality relative to other > >subproblems in the pool to save some time. Otherwise, too much effort is > >wasted. > > This is an area which needs a lot of work. At present it is very crude. > The user can say do every k nodes or if -1 then it checks every 100 nodes > if any cuts are generated - anyway that's approximately what happens. OK. Then I may try to improve on it. > >Second, what does the solver_ in the model of SbbHeuristic object > >correspond to? Can I make sure that when a heuristic is called, it > >contains the current subproblem with relaxation solved to optimality > >(i.e., proper LP basis loaded)? Will all applicable cuts be "in"? > >Third, will I be able to use some cut generators inside the heuristic (it > >is really a heuristic branch-and-cut)? > > In SbbHeuristic model_->solver() gives the OsiSolverInterface pointer to > current model (with cuts and optimal). The underlying solver will be same > one set in main program. model_->continuousSolver() should give model with > initial state. This is perfect -- exactly what we need. > At present you can use cut generators in the heuristic but there is no way > to pass these cuts back. If you were going to then the code should really > be in as a cut generator? If you are going to modify model then clone the > solver and modify that. It may prove difficult in the most general version of the heuristic, since cuts are generated using by-products of heuristic run. Thanks a lot for the advice. Best, Mikhail Nediak > > Please keep the questions coming. > > John Forrest > > -------------------------------------------- > > Mikhail, > > > > Sbb uses the Osi interface. I am at present working on a first version > of > > an integer presolve, which for the moment assumes that the user is > actually > > using clp as the solver. So I do a dynamic cast to clp and then use > Clp's > > presolve. I intend to enhance that presolve and also give it an osi > > interface. > > > > However I think it valid to allow the casting to clp and then using clp > > interface so my question to you is - do you want to do things at the Osi > > level or Clp level. If at the Clp level I have more freedom. > > > > If it is at Clp level, what exactly do you want? For primal pivot in > > choice or dual pivot out choice it is easy - for primal look at > > ClpPrimalColumnPivot.hpp and ClpPrimalColumnDantzig.?pp (as that is > > simplest). The corresponding pivot out/pivot in is more problematic but > > anything can be done. > > > > So give me a hint. Also if you think your requests are of sufficient > > generality, indicate that and I can post replies to coin-lpsolver and/or > > coin-contest. > > > > John Forrest > > > > > > > > > The original note from Mikhail. > > I am trying to test certain pivot-based heuristic with Sbb and the current > interface does not seem sufficient. So I will have to, most likely, modify > the place in the Sbb code where it is called (and, also the manner and > the frequency of the calls). Could you please give me some suggestions on > where I should start? Any advice is greatly appreciated. > > _______________________________________________ > Coin-contest mailing list > Coin-contest@www-124.ibm.com > http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-contest > From robinlh at us.ibm.com Tue Jan 28 22:00:26 2003 From: robinlh at us.ibm.com (Robin Lougee-Heimer) Date: Wed Nov 24 00:04:11 2004 Subject: What does improve speed but not functionality mean? (Re: [Coin-contest] Re: SBB) Message-ID: JJHF: >I may work on improving the >speed of existing code (and fixing bugs), >but not on the functionality. Could you please elaborate on what your intentions are when you say "improve the speed of exisiting code but not on the functionality". For instance, heuristic functionality exists. So, technically you could "speed the code" by adding a new heuristics without increasing the functionality. Do you mean to say after 6pm EST Feb 6th there will be no new heurisitcs? No new cuts? No new preprocessing? No improvements to existing cuts? thank you in advance for the clarifications, Robin ---------------------------------------------------------------------------------- Robin Lougee-Heimer IBM TJ Watson Research Center ph: 914-945-3032 fax: 914-945-3434 robinlh@us.ibm.com http://www.coin-or.org John J Forrest/Watson/IBM@IBMUS@www-124.southbury.usf.ibm.com on 01/26/2003 04:08:08 PM Sent by: coin-contest-admin@www-124.southbury.usf.ibm.com To: John Dethridge cc: Coin-contest@www-124.southbury.usf.ibm.com Subject: [Coin-contest] Re: SBB John, As this may be of interest to others, I am posting my reply to coin-contest. The intent is that by the end of January - not later than 6pm EST February 7 the Sbb code will be functionally frozen. I may work on improving the speed of existing code (and fixing bugs), but not on the functionality. I will also be improving the documentation etc etc. If you have any concerns, please raise them. John Forrest John Dethridge cc: Subject: SBB 01/25/2003 10:57 PM Hello Mr. Forrest, I was wondering if you were planning on making any more changes to the SBB code before the end of March. It is hard to start working on the contest when anything we write might become redundant! Thanks, -John Dethridge _______________________________________________ Coin-contest mailing list Coin-contest@www-124.ibm.com http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-contest From jjforre at us.ibm.com Wed Jan 29 08:55:55 2003 From: jjforre at us.ibm.com (John J Forrest) Date: Wed Nov 24 00:04:11 2004 Subject: [Coin-contest] Cut generators etc Message-ID: As working with cut generators is an obvious way to enter this contest, I thought I would make some remarks on the current state of the generators and point out some of their defects. Fixing defects will definitely get bonus points from me. In this area it is very easy to make mistakes - normally a plus is used instead of a minus or some such. This has one of two results: 1) Illegal cuts are generated - often leading to better run times! The way to find these is to switch on the cut debugging tool in OsiRowCutDebugger which can recognize a problem, plug in an optimal solution and then complain if any cuts cut off this solution when they should not do so. I will try and increase the number of problems for which OsiRowCutDebugger.cpp knows the solution - if anyone has solutions already please send them to me. 2) Much harder to find are the cases where the cuts are weakened. Personally, I would think that fixing such a bug in existing generators can be as useful and challenging (and should recieve as much credit in the contest) as creating a new (and possibly buggy) cut generator. One good way of tracking down such bugs is to see if two equivalent problems give same cuts e.g. turn a <= row into a >= row and switch signs. The existing cut generators are: CglGomory This is fairly well tested. There can be problems of accuracy with long cuts, but that is the nature of the beast. There may still be negative bugs and I may put in one minor improvement to do with implicit integer slacks. CglKnapsackCover Again this is fairly well tested. It currently contains alternate methods for finding covers (greedy, heuristic, exact) and alternate methods for lifting (sequential, simulataneous). Additional cover finding and lifting ideas could be put in, especially those that take advantage of other problem information such as cliques would be a good area for coding. CglLiftAndProject There are a whole cadre of lift-and-project cuts using different norms This cut generator is an implementation of only one, the most basic one, what is called "Norm1" in the lift-and-project literature and does not make use of all the published lifting results. It assumes that the user only invokes it when appropriate. Much could be done here. This is not very well tested and should be made to fail gracefully when such cuts are not applicable. CglOddHole This works - sort of. I don't think it has any bugs which create false cuts but I am fairly sure it has bugs which prevent it from creating cuts, I found a stupid one just yesterday. A complete re-write could be the best way forward. CglProbing Probing (changing a bound on an integer variable and seeing what happens is normally thought of as preprocessing, and not as a cut generator, however if a continuous variable goes to a bound then you may be able to get a disaggregation cut and if a constraint goes slack when a variable is fixed you may be able to strengthen a coefficient in that constraint, This is fairly solid. It may not do as much as it should. It can fix variables and with the correct options do coefficient strengthening and disaggregation. If there's any preprocessing capability/information that would be useful for you to have for your own work, I would be glad to hear requests. For coefficient strengthening it produces a new cut with the strengthened coefficient (as opposed to actually changing the coefficient in the matrix). At the root node it might be useful to allow it to replace the constraint -. I may re-work cuts to make that easier. CglSimpleRounding This was designed as an example and I think will always be dominated by other cuts. It would be interesting to switch it on and see if it does produce any cuts not generated by other generators. The question of how to avoid duplication of cuts and so on is also interesting. I will be working on making these generators faster by preselecting promising rows and by decreasing the frequency of trying some generators. .There is some crude coding in Simple Branch and Bound, but it needs improvement. - this should be done as modifications to SbbCutGenerator. Is there any extra functionality you would like to have..? Now over to you Robin to discuss possible new cut generators. John Forrest