MIPIII Frequently Asked Questions

SOFTWARE
Overview of MPSIII
C-Whiz Optimizer
Mixed Integer
Modeling Languages, Dataform & OML
Oml Library Optimizers and Model Building
Applications
SERVICES
Consulting
Technical Support

Select Link below for Frequently Asked Questions About Our Other Products

  FAQ C-WHIZ   FAQ DATAFORM   FAQ MPSIII   FAQ LOPTIS   FAQ OML  

How can I stop a MIP run before it is finished?

Once you get into the mixed-integer phase of the model run, MIPIII turns off the LP log-lines, but sends the more interesting branch-and-bound log to the screen. During this phase you can press the Q key to cause MIPIII to pause. It will give you a short summary of the solution status and ask your permission to continue or to terminate the branching process.

Back to the top

How many integer variables can I have in a model?

We impose no practical limit. The thing that you must keep in mind is that the branch-and-bound search tree can get very large. When you have a model with a large number of integer variables, expect it to take a while to solve and prove global optimality. MIPIII provides quite powerful control mechanisms for guiding MIPIII and for terminating the search without having to look at the entire tree.

We are NOT saying that you can have as many 0/1 variables as you want. MIPIII has a design limit of 32,767 integer variables and sets in a model. This limit is well beyond the practical number of integer variables.

However, every 0/1 variable potentially doubles the number of branches in the branch and bound tree. Remember that 2 to the 100th is a very big number and 2 to the 1000th is an impossibly big number. Depending on what you are modeling, you might want to consider an alternate formulation such as using special ordered sets - e.g., in a forest management model you might have one set for each stand and one member of the set for each regime.

Another option is to abandon the thought of using 0/1 variables. If you have only a few hundred or even 1000 constraints, the number of basic vectors will be relatively small. This means that almost all of your variables will naturally be at limit, i.e., either 0 or 1, at the continuous optimal solution.

Back to the top

I have been running MIPIII and getting answers that aren't full integers. The numbers are very close to 0 and 1 ( eg. 0.000521 and 0.999479), but they aren't exactly, and this is making a big difference in my model output. I'm not that familiar with hardware specifications, and compatibility, and stuff like that, but someone in our office mentioned that it could be your software is 16-bit and my computer is 32-bit, and therefore remembers more info than it should. Can you shed any light on this?

The 16 bit vs 32 bit idea is an imaginative guess, but it is not correct. Because of the severe requirements for computational accuracy, math programming optimizers can survive only in the world of double precision. The 32 bit PC word is at the lower edge of acceptability for us.

The phenomenon that you observed is caused by a compromise built into MIPIII. This is a compromise between solution accuracy and processing time. During the branch and bound process variables are fixed at 1 or 0; in this case, they are exactly at 1 or 0. However, once we have optimized one of the nodes, MIPIII looks at all of the other integer variables (those that have not been fixed at 1 or 0) to see if they are naturally at 1 or 0. If so, we have an all integer solution and can stop analyzing this branch of the tree. This test for 1 or 0 is done within a tolerance and becomes: "is this variable close enough to 1 or 0". The standard tolerance for MIPIII is .001; a value that is close enough for most applications. You will notice that the discrepancies that you report are smaller than .001.
Fortunately, this is not something that have to live with. One of the MIPIII control tables (T:STRATEGY) can be used to specify a new value for the integer tolerance, TOLI. Include in the table a new row that says:
  TOLI    .0001
for instance. The immediate result is that MIPIII will not accept numbers such as .0005 as good enough and will push on until it gets an acceptable answer. This might cause unacceptable or worrisome run times, but that is the tradeoff.

Back to the top



©Copyright 1998-2011 Ketron Optimization. All Rights Reserved.

Home Page   MPS Tools   Optimization & Modeling Library  Model Management   Consulting Services  Contact Us   Downloads  Feedback 

Send comments and suggestions to: Webmaster