Conversation
|
Nice. Let me take a closer look. Definitely in love with this patch/PR!!! |
Rlahuerta
left a comment
Rlahuerta
left a comment
There was a problem hiding this comment.
I was testing and using python 2.7 is giving the following error:
Starting at previous solution and solving again
Traceback (most recent call last):
File "hs071_PY3_warm.py", line 147, in
mult_x_L=zl, mult_x_U=zu)
TypeError: argument 3 (impossible)
|
It's been a year since I did this, but I'm pretty sure this is why I put "PY3" in the script name. I imagine someone could modify to support Python 2. |
|
Has this already been merged into the master branch, @xuy ? Thank you very much! |
|
|
||
|
|
||
| nlp = pyipopt.create(nvar, x_L, x_U, ncon, g_L, g_U, nnzj, nnzh, eval_f, eval_grad_f, eval_g, eval_jac_g) | ||
| nlp.str_option('warm_start_init_point', 'yes') |
There was a problem hiding this comment.
I apologize for getting back to this PR after, hmm, two years. 😞
Just merged another PR of python3 support, so we have one version of hs071 as example. I wonder if the following 5 lines can be added to example with an if toggle.
|
|
||
| PyObject *solve(PyObject * self, PyObject * args) | ||
| // too much cut and paste ... | ||
| #define SOLVE_CLEANUP() { \ |
|
|
||
| PyObject *solve(PyObject * self, PyObject * args, PyObject * keywds) | ||
| { | ||
| static char *kwlist[] = {"x0", "userdata", "mult_g", "mult_x_L", "mult_x_U", NULL}; |
There was a problem hiding this comment.
I see. there is a subtle API change here (from args to kwargs), let me actually play with it a bit before saying it is good or bad.
|
@andrewcron |
5 participants
Hi Everyone,
I've added a new feature to allow the appropriate parameters to be passed to
solveto perform warm start optimization. (See http://www.coin-or.org/Ipopt/documentation/node49.html.) I've also included a new example variant ofhs071_PY3.pyto demonstrate the process.The primary change is the option to pass the various bound multipliers returned from a previous optimization to the
solvefunction as keyword only arguments along with some error checking. If they are passedmL,mU, andlambdainsolveare initialized instead of passed as empty arrays. When thenlp.str_option('warm_start_init_point', 'yes')option is set, these arrays will be read and the optimization will pretty much pick up where it left off.This helps solve a very common problem where the objective only changes slightly between runs of the optimizer, so we don't want to completely reinitialize if the optimization is expensive.
Thoughts?
Thanks!