Originally posted by: Mark L. Stone

The technote "Guidelines for estimating CPLEX memory requirements based on problem size" http://www-01.ibm.com/support/docview.wss?uid=swg21399933 apparently predates the introduction of the global QP solver in CPLEX 12.6, i.e., use of solutiontarget = 3 (globaloptimall) for a non-convex linearly constrained QP.  Are there memory guidelines for globally solving non-convex QPs, I suppose with perhaps some variability along the lines of solving MIPs due to variation in number of branch and bound nodes incurred in the solution process?  Are there settings which affect branching, number of open nodes, computation per node, and therefore trade off memory usage vs. computation speed, or things along those lines, as there are for MIPs?

Thanks.

Originally posted by: PierreBonami

Hi Mark,

The guidelines for MIP would apply (the algorithm employed for global QP basically uses the same framework).

Best

Originally posted by: Mark L. Stone

Can you speak specifically to the applicability of MIP parameters to control the global QP solver - exactly which parameters are available and what they do?  Perhaps that's an area of documentation which can be beefed up for the next documentation release,but in the meantime ...

Also, the following was buried in a thread about using starting values for MIP:

Does "advanced start switch" apply to Global QP solving (solutiontarget=3)?  If not, is there a way to provide starting value(s) to the global QP optimizer, either for the variables or for a branch and bound tree?

Thanks.

Originally posted by: Mark L. Stone

Bump.  Thanks.

Originally posted by: PierreBonami

The parameters that should have an effect and work are in particular using a node log file (this should not hurt performance too much) and changing the node selection strategy to depth first search (this could have much worst effect on performance depending on how easy it is too find a good solution). Also limiting the number of threads (of course this will also reduce speed).

Note however that solving non-convex QP can indeed be somewhat more memory hungry because branching is not only based on bounds changes but also on using cuts.

Do you have a specific problem on which you have troubles?

Best,

Pierre

Originally posted by: Mark L. Stone

Pierre, this is a matter for now of understanding options.  Since I am currently using the preview edition (which limitation I will hopefully soon be free of), for now I can only solve toy problems for which memory is not an issue, at least for the problems I've been dealing with.  But at some point as I scale up, I expect memory, run-time, or both to come into play, and I would like to understand the tradeoff opportunities.  Thanks.