Surprising value of inf_du when warm-starting. #558
-
Moving from issues page I was playing around with an idea and noticed something odd. I first solve a problem and restrict the number of iterations to be 1. I then create a new solver instance, and warm-start with the output of the first solution call (1 iteration in). I initialize the primal and dual solutions, and specify the warm-start parameters as seen below. What is surprising is that at initialization of the second solve, the inf_du value does not match what it was at the termination of the first solve. Is this expected behavior? I would like to instantiate the solver for the second call at precisely the internal state it was at after 1 iteration of the first call. Apologies if this is not the correct place to ask this question. First Solve
Second Solve
Ipopt parameters (note I am calling the C-interface via Julia / IPOPT.jl. These options are used in both the first and second calls above. )
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
The Julia interface builds on the C interface, which again builds on the C++ interface. So there is some complexity. If you set print_level to 8 or higher, then from the first solve, you should get an output like
And for the second solve, you should get output starting with something like
If you do not get the duals from the first solve, maybe something needs to be done on the Julia side. There is a mention of a If Ipopt receives the correct duals, then the following detailed Ipopt log will hopefully indicate what is happening with them next. |
Beta Was this translation helpful? Give feedback.
The Julia interface builds on the C interface, which again builds on the C++ interface. So there is some complexity.
Thus, please first check that the dual solution correctly arrives in Ipopt.
If you set print_level to 8 or higher, then from the first solve, you should get an output like