[Dip] Issues related to Dippy source code

[Marcus Kaiser]

Hello Dip/Dippy Community,
I am currently working on my master's thesis in mathematics. First of 
all, I want to express my appreciation for the efforts of the Dip team. 
I'm happy to be able to rely on such a comprehensive framework. To 
implement a Dantzig-Wolfe decomposition with custom initial solution and 
custom solver for the subproblems, I used the Dippy package in Python. 
During the process, I stumbled upon some lines of code in Dippy that I 
wonder about. The version that I run is 0.91.5 compiled with MSVC 2015 
for Python 2.7.10 x64 on Windows. Even though I have not yet been able 
to use 0.92.1, the following comments refer to its source.

 1. DippyPythonUtils.cpp, line 274: The method pyColDict_AsPackedArrays
    calls getVarType on a Python object of type pulp.LpVariable which I
    found to have no such method. This produces an error when I try to
    supply an initial solution. As the result of the call to getVarType
    is not used anyway, maybe the line can be deleted.
 2. DippySolve.cpp, line 31: The definition of DecompInf leads to a
    compiler error as it is also globally defined in DecompAlgo.cpp,
    line 43. It does not seem to be used in DippySolve.cpp, though.
 3. DippyDecompAlgo.cpp, line 47: The assertion in this line does not
    allow the fallback to the default implementation of
    DecompAlgo::chooseBranchSet to return false. This yields an error if
    the column generation is stopped due to lacking improvement and
    chooseBranchSet is called for an integer solution. In general, the
    usage of chooseBranchSet in
    AlpsDecompTreeNode::chooseBranchingObject (AlpsDecompTreeNode, line
    379) suggests that the return value false would also be acceptable.
    However, I could not figure out what happens to a node if this is
    the case and the status is set to AlpsNodeStatusEvaluated. Does it
    proceed with column generation? Maybe, the failure of
    chooseBranchSet should be allowed in Dippy and be propagated to DIP.
 4. dippy.py, line 852 sqq.: As I understand the cost and reduced cost
    for a column is computed here if relaxed_solver returns a dictionary
    for the variable values without including those corresponding costs.
    The value of target, however, is not taken account of in this
    calculation. This would mean incorrect testing for negative reduced
    costs in my opinion. To what extent are the cost values returned by
    DipProblem.solveRelaxed used by DIP? I took from a thread of the
    mailing list in July that there are cases where DIP solves the
    subproblem as MILP. Is it possible to prevent DIP from doing so
    completely? Is returning an optimal solution with an appropriate
    status from relaxed_solver enough to do so? Is it valid to return a
    set of several solutions containing an optimal as well as many
    non-optimal solutions while specifing the status as optimal? The
    reason why I would like to know is that my subproblems are quite
    large when formulated as MILP. Therefore, at the moment I provide
    DIP with dummy MILPs for the subproblems which serve the only
    purpose of establishing the assignment of variables to their
    subproblem. They do not make any sense, though. That is why I would
    like to make sure that DIP relies on the custom solveRelaxed method
    only and does not use more information from the MILP formulation
    than the occurence of variables.

Thanks in advance for your help,
Marcus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/dip/attachments/20151024/90de85a4/attachment.html>