change model after solve, then resolve about csip HOT 27 CLOSED

Ok, the freeTransform kills the best solution....

from csip.

This is a bit random, but:

there is this warning in the SCIPcreateVarBasic docu

To get the objective value correctly, we may use SCIPgetBestSol and then SCIPgetSolOrigObj or SCIPgetSolTransObj depending on the stage we are.

What about solving the transformed before calling solve?

CSIP_RETCODE CSIPsolve(CSIP_MODEL* model)
{
   SCIP_in_CSIP( SCIPfreeTransform(model->scip));
   SCIP_in_CSIP( SCIPsolve(model->scip) );

   return CSIP_RETCODE_OK;
}

from csip.

OK, so I got an error, because I was using wrong methods (w.r.t. to solving stage) to query the objective value, apparently.

What would it help to call freeTransform before solve? My expectation is, that solve will trigger the transformatioanotn, so it's actually a no-op.

from csip.

SCIPfreeTransform is going to change the stage to PROBLEM (we are never in INIT, because we create a problem as soon as we create SCIP and users can't free problems)... as you said, if you do SCIPsolve twice it will do nothing the second time.. calling SCIPfreeTransform will change the stage and then the second time you call SCIPsolve it will do something.

from csip.

I see what you mean. But can I still add constraints after solve?

from csip.

Doesn't work though, I would now get now get this error:

[src/scip/scip.c:403] ERROR: cannot call method <SCIPsetObjsense> in problem solved stage

from csip.

according to the docu, no you can't.
What would we lose if we call freeTransform after solve?

from csip.

I'm testing it right now, and replaced getPrimalBound with getSolOrigObj(getBestSol). There are no SCIP errors now, but I think the getBestSol does not understand changes in the objective sense 😕

from csip.

but what would you expect? if you change the sense, you have to optimize again

from csip.

Of course. In the test (test_lazy), we change the sense, and then call solve. Maybe the issue is another one.

from csip.

I can't figure it out. According to the log output, the correct solution is found (with value 2.5), but when I ask for the objective value it's 0.0, for the solution (0.0, 0.0) and not (1.0, 2.0).

### added lazy constraint!
feasible solution found by trivial heuristic after 0.0 seconds, objective value 1.500000e+00
presolving:
(round 1, fast)       0 del vars, 0 del conss, 0 add conss, 1 chg bounds, 0 chg sides, 0 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
(round 2, fast)       1 del vars, 0 del conss, 0 add conss, 1 chg bounds, 0 chg sides, 0 chg coeffs, 0 upgd conss, 0 impls, 0 clqs
   (0.0s) probing cycle finished: starting next cycle
presolving (3 rounds: 3 fast, 1 medium, 1 exhaustive):
 1 deleted vars, 0 deleted constraints, 0 added constraints, 1 tightened bounds, 0 added holes, 0 changed sides, 0 changed coefficients
 0 implications, 0 cliques
presolved problem has 2 variables (1 bin, 1 int, 0 impl, 0 cont) and 0 constraints
transformed objective value is always integral (scale: 0.5)
Presolving Time: 0.01
transformed 1/2 original solutions to the transformed problem space

### added lazy constraint!
 time | node  | left  |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols |rows |cuts |confs|strbr|  dualbound   | primalbound  |  gap   
t 0.0s|     1 |     0 |     0 |     - | 192k|   0 |   - |   2 |   0 |   0 |   0 |   0 |   0 |   0 |      --      | 2.500000e+00 |    Inf 
### added lazy constraint!
  0.0s|     1 |     0 |     0 |     - | 192k|   0 |   0 |   2 |   0 |   2 |   0 |   0 |   0 |   0 | 3.000000e+00 | 2.500000e+00 |  20.00%
### added lazy constraint!
  0.0s|     1 |     0 |     0 |     - | 193k|   0 |   0 |   2 |   1 |   2 |   0 |   0 |   0 |   0 | 3.000000e+00 | 2.500000e+00 |  20.00%
(run 1, node 1) restarting after 2 global fixings of integer variables

presolving:
presolving (1 rounds: 1 fast, 0 medium, 0 exhaustive):
 2 deleted vars, 0 deleted constraints, 0 added constraints, 0 tightened bounds, 0 added holes, 0 changed sides, 0 changed coefficients
 0 implications, 0 cliques
Presolving Time: 0.01

SCIP Status        : problem is solved [optimal solution found]
Solving Time (sec) : 0.01
Solving Nodes      : 0 (total of 1 nodes in 2 runs)
Primal Bound       : +2.50000000000000e+00 (4 solutions)
Dual Bound         : +2.50000000000000e+00
Gap                : 0.00 %
### objval = 0.000000 
### sol: 0.000000, 0.000000
test: /home/rs/src/CSIP/test/test.c:336: test_lazy: Assertion `fabs(solution[0] - 1.0) <= 1e-5' failed.

Anyway, all of the last three tests fail (for various reasons), so I don't want to commit this change now.

from csip.

can you push? or create a branch, so I can see it plz

from csip.

Yes, on branch freeTransform.

from csip.

Apparently, the best solutions in the transformed problem are only copied in a candidate pool, which SCIP will check at the next sol (or presol), but not in PROBLEM stage

1. We can store the solution ourselves
2. Call SCIPfreeTransform in all methods that modify the problem

I (Robert) personally prefer the first option

from csip.

Do we have a test that covers changing the model and resolving?

from csip.

Yes, the one where I change the optimization sense (and back).

EDIT: But to make those work, I had to apply solution 2 above, that is, call freeTransform within setSenseMaximization.

from csip.

the bug is fixed by f6b7ba2 and a3cc475

from csip.

Sorry, still broken. Apparently the solution is still lost after freeTransform.

from csip.

so this is a bug on the SCIP side. The solution is actually not lost after the freeTransform. After freeTransform, SCIP will copy the solutions to the original problem. However, SCIP sorts the solution by objective value assuming always that less is better

A possible fix (on the SCIP side) is to reverse the order of the solution if the problem is maximization.

A possible fix (on the CSIP side) is to ask for the last solution instead of the bestSol, when problem is maximization

from csip.

I prefer fixes on the CSIP side, but is asking for the last solution really robust?

My last commit proposes a workaround, where we do the reformulation to "minimization" in CSIP. However, it still doesn't work for the tests where we solve multiple, modified problems.

Maybe we should clear the solution pool just before doing a SCIPsolve?

from csip.

why wouldn't it work if you change to minimize????

it might make sense to clear the solution pool, though it might affect the
resolve making it slower

On Fri, Jun 17, 2016 at 7:50 AM, Robert Schwarz [email protected]
wrote:

I prefer fixes on the CSIP side, but is asking for the last solution
really robust?

My last commit proposes a workaround, where we do the reformulation to
"minimization" in CSIP. However, it still doesn't work for the tests where
we solve multiple, modified problems.

Maybe we should clear the solution pool just before doing a SCIPsolve?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#2 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AFNG9iKN23hpp05m5UjkiZqrUH0-qmsxks5qMjW-gaJpZM4IzpyS
.

from csip.

The failing test objsense first minimizes then maximizes a problem. I have not looked into it deeply, but I'm guessing that the solution from the first run has a value smaller than the negated value of the second run's solution.

from csip.

I guess clearing the solution pool would be SCIPprimalFree, but that is not public, and I don't think it will be resurrected with a new solve.

from csip.

Of course, we could still go back to the workaround of storing our own solution, next to the status.

from csip.

you can probably go through all sols and call SCIPfreeSol

I don't like storing the solution

but this is weird, it should be failing let me have a look

On Fri, Jun 17, 2016 at 8:07 AM, Robert Schwarz [email protected]
wrote:

Of course, we could still go back to the workaround of storing our own
solution, next to the status.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#2 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AFNG9grh6j9TGcuf7HEkD1gMe0mHozVBks5qMjmfgaJpZM4IzpyS
.

from csip.

okay, so it is failing because:

1. problem is minimize x ---> solving just solves
2. change to max --->problem is maximize x ----> solving changes to minimize -x and solve
3. change to min ----> problem is minimize -x -----> solving just solves

In 2) at the end, you should reset your changes ;)

from csip.

OK, I shouldn't code before breakfast ;-)

from csip.