[Scip] Adding constraints following completed pricing

[Gerald Gamrath]

Dear Rostislav,

no, that should not happen, there should not be an unauthorized memory
access when calling SCIPfreeTransform() if you added constraints during
solving. We should have a look at that.
Please compile your code in debug mode (make OPT=dbg), if you did not do
that already. Then, run it with gdb or perhaps even valgrind and please
send us the backtrace or the exact error output you get. Perhaps we can
identify the problem using this information. Besides, if possible, you
can send your code to me directly so that I can check it in detail.

Best,
Gerald

Am 06.12.2012 13:42, schrieb Rostislav Stanek:
> Dear Gerald,
>
> thank you for your response.
>
> Yes, it is a kind of a separation - in my problem I have a huge amount 
> of constraints, however only a very few of them are active after solving 
> the problem. So my idea was to solve the relaxed problem first. Then I 
> was able to find the violated constraints easily and to add them to the 
> problem after calling SCIPfreeTransform(). Finally I resolved the 
> problem and repeated the described process until the solution was 
> feasible (I needed about 4 - 5 runs of the solver).
>
> The next idea was to speed up the solving process by adding some 
> constraints during the process (e.g. if an integral solution is found), 
> but as I mentioned in the last mail, it doesn't work. It doesn't also 
> work if I don't want to keep the constraints added during the solving 
> process and if they are added only to speed up the one run of the 
> solver. I get unauthorized memory access (SIGSEGV) (core dumped) (I hope 
> that I am translating the message correctly) by calling SCIPfreeTransform().
>
> Is it the correct behaviour of the solver or am I doing something wrong?
>
> Thank you for your response again.
>
> Best regards
>
> Rostislav
>
>
>
> Dne 6.12.2012 12:53, Gerald Gamrath napsal(a):
>> Dear Rostilav, der Stephen,
>>
>> you are right, by calling SCIPfreeTransform(), you can throw away the
>> complete solving data and get back to the original problem from before
>> you started solving. In particular, this means that all constraints and
>> variables are removed, that were created during the solving process.
>>
>> @Rostilav: What kind of constraints does your event handler add during
>> the solving process and why? Shouldn't it add those again when solving
>> the problem again, if they are still needed? And if they are always
>> needed, why don't you add them at the beginning? Is it kind of a separation?
>> If you want to keep the constraints, one possibility would be to copy
>> the global problem via SCIPcopy(). However, the global problem in this
>> case is defined w.r.t. the current soulution process, e.g., some
>> constraints might be disabled or variable domains might be reduced
>> because of information SCIP collected about the current problem. These
>> reductions might not be valid anymore when you change the problem of the
>> copy afterwards, e.g., by changing objective coefficients. So you have
>> to be careful about that, too, and somehow reset everything to the
>> initial values. This is what is done when freeing the transformed
>> problem, but then you loose the constraints added during the solving
>> process for the same reason: SCIP does not know whether they are
>> globally valid or just valid because of other information found during
>> the solving process.
>>
>> @Stephen: You also need to use SCIPfreeTransform(), which means that all
>> the solving data is thrown away. This is done because by changing the
>> problem, dual and especially primal bounds are changed and it might be
>> that some nodes were cut off that now need to be considered. There is
>> currently no way to keep the already created variables, what you could
>> do is store them in your pricer and then create them all when starting
>> to solve the modified problem.
>> Again, you can alternatively copy the global problem (don't forget to
>> set the flag that enables pricing). In your case, this might be a good
>> solution, because the constraints that contain priced variables should
>> be marked modifiable and thus were probably not changed during the
>> solving process, you just have to ensure that the variable's bounds are
>> reset.
>>
>> Best,
>> Gerald
>>
>> Am 06.12.2012 09:44, schrieb Rostislav Stanek:
>>> Hello Steve,
>>>
>>> I had the same problem. You can use
>>>
>>> SCIP_CALL_EXC(SCIPfreeTransform(scip));
>>>
>>> to get back to the starting point. Than you can add new constraints and
>>> solve the problem again.
>>>
>>> But this works well only if no constraints had been added during the
>>> solving process (e.g. by an event handler). I don't know how to solve it
>>> in the other case - actually I am still looking for a solution (without
>>> success).
>>>
>>> Best regards
>>>
>>> Rostislav
>>>
>>>
>>>
>>>
>>> Dne 6.12.2012 06:10, Stephen J Maher napsal(a):
>>>> Hi all,
>>>>
>>>> I am solving a problem using column generation and I would like modify
>>>> the problem once an optimal solution is found. I would like to add a set
>>>> of constraints to the problem and then solve this updated problem. The
>>>> problem will always remain feasible with the added constraints, but the
>>>> objective value will change.
>>>>
>>>> I am not too sure of the best way to implement this. Any help would be
>>>> appreciated.
>>>>
>>>> Thank you,
>>>>
>>>> Steve
>>> _______________________________________________
>>> Scip mailing list
>>> Scip at zib.de
>>> http://listserv.zib.de/mailman/listinfo/scip
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip