Free Python optimization framework

Sunday, June 29, 2008

scale parameter for lpSolve

I have committed scale parameter (bool flag) handling for lpSolve.

It should be used as

p.solve('lpSolve', scale = 1)
p.solve('lpSolve', scale = True)

Friday, June 27, 2008

bugfix for constrained NLSP graphic output

I have committed the bugfix mentioned in OO GSoC timeline.
Here's graphic output for a little bit modified /examples/

Tuesday, June 24, 2008

bugfix for ralg A, Aeq constraints handling

I have committed bugfix for ralg A, Aeq constraints handling.
Unfortunately, the bug is present in 0.18, when I add Point class.

connecting algencan 2.x beta

Some weeks ago I had downloaded and compiled algencan 2.0 beta (version from March 25). Now new version is available: 2.0.1 beta, but currently I fail to compile both these versions (I guess because of some KUBUNTU updates). Fortunately, I can use those old compiled files from 2.0 beta.

So I have provided OO-algencan 2.0 beta connection (I guess it should work with 2.0.1 as well).

On the other hand, v 1.0 works better than 2.0beta (at least for those examples I have examined). Mb v. 2.0.1beta or v. 2 release will work better?

also, pay attention to the issues:

  • you should remove old algencan files (first of all that is situated somewhere on your PYTHONPATH). Mb I could use some tricks to allow both ALGENCAN (i.e. 1.0) and algencan (i.e. v 2.x) to be available in OO, but it requires some more efforts, and I don't see much sense because in future ALGENCAN support will be ceased.

  • provide algencan with either bigger gradtol (1e-1...1e-5 instead of default 1e-6) or other stop criteria like maxTime, maxCPUTime, maxIter, maxFunEvals

  • you can encountered text output "PYTHON INTERFACE ERROR: in evalg, PyEval_CallFunction returned NULL" - this one is due to stop triggering (maxTime, maxCPUTime etc, via Python exception) of artificially binded OO iterfcn, because currently algencan has no native one (here's the thread with my proposition to create the one)

  • Monday, June 16, 2008

    bugfix for ipopt linear constraints handling

    I have committed bugfix for ipopt linear constraints handling Ax<=b, Aeq x = beq.
    I just forgot to implement the one because ipopt API has only x_L <= x <= x_U and g_L <= g(x) <= g_U constraints.

    Sunday, June 15, 2008

    OpenOpt 0.18

    Hi all,
    I'm glad to inform you about new OpenOpt release: v 0.18.

    Changes since previous release 0.17 (March 15, 2008):
    • connection to glpk MILP solver (requires cvxopt v >= 1.0)

    • connection to NLP solver IPOPT (requires pyipopt installation, that is currently available for Linux only)

    • major changes for NLP/NSP solver ralg

    • splitting non-linear constraints can benefit for some solvers

    • unified text output for NLP solvers

    • handling of maximization problems (via p.goal = 'max' or 'maximum')

    • some bugfixes, lots of code cleanup

    Regards, Dmitrey.

    major changes for ralg

    I have committed some major changes for ralg (+ some more code for prob.point, to simplify my further OO development).

    Since I have been busy with connecting ipopt and these ralg changes, patterns are intended to be implemented in next OO release.

    Below is output of OO v0.17 ralg vs current ralg implementation (made by /examples/ for N=100). Usually OO v0.17 ralg consumes about 5-10% objFunc and 3-5% nonlinear constraints evaluations greater.

    Thursday, June 12, 2008

    Connecting IPOPT, Part 3

    I have wrote automatic generation of ipopt.opt file. That one is read from current directory; to omit creating of the one (and hence all-defaults or using ipopt.opt file from current directory) use
    r = p.solve('ipopt', optFile = False)
    (default value for optFile is "auto", also, I intend to provide possibility for loading the file from given location, like
    optFile = "\\home\\dmitrey\\myipoptsettings.opt"

    Currently it consists of 3 lines:
    print_level -2 (to suppress annoying huge text output)
    tol (p.ftol is put here)
    constr_viol_tol (p.contol is put here)

    I found it too long and complicated to implement all those parameters with their default values (and hence duplicate ipopt code) that are can be changed by IPOPT developers from time to time (and it's hard to monitor), so to add other fields from ipopt.opt file specification you should use "options" as string (comma and semicolon delimiters can be used here, and space or "=" can be delimiters for option name and value), not as Python *args or **kwargs.


    r = p.solve('ipopt', options = 'dual_inf_tol=1.005; compl_inf_tol 1.005e-4, alpha_for_y dual-and-full')

    Let me also remember you that running ipopt from OO requires pyipopt installation, and currently pyipopt is Linux-only. Also, some days ago pyipopt bug related to fail on problems w/o non-linear constraints has been fixed.

    Saturday, June 7, 2008

    numpy-related bug

    If you have encountered problems (during using OO) like the one:
      File "/usr/lib/python2.5/site-packages/scipy/sparse/", line
    139, in spmatrix
    TypeError: deprecate() takes exactly 3 arguments (1 given)
    then numpy update is recommended (and using OO from latest tarball or svn), as it is mentioned here.

    Friday, June 6, 2008

    Unified text output

    I have turned NLP/NSP/GLP solvers to show unified text output. That one can be edited by user (I'll publish detailed description in OO Doc page ASAP).

    Now it's like this for constrained problems:

    iter objFunVal log10(maxResidual)
    0 6.115e+01 2.13
    10 2.360e+01 0.72
    20 1.754e+01 0.38
    1290 2.015e+01 -6.23

    and like this for unconstrained (or those problem-solver pairs which always have feasible iter points, for example some box-bounded problems and solvers):

    iter objFunVal
    0 -2.825e+06
    10 -7.106e+05
    1570 -4.787e-03

    Maximization problems

    I have committed some changes, they allows handling of maximization problems

    objFunc -> max
    (subjected to some constraints)

    via p.goal = 'max'
    (or 'maximum')

    Currently LP, MILP, QP classes have no the possibility, it's only valid for NLP, NSP, GLP

    of course, the parameter goal could be used in prob assignment or solve function as well:
    p = NLP(..., goal='max')
    r = p.solve(solverName, ... (other parameters), goal='max')
    here's graphical output from modified (using -f instead of f, already in subversion).

    Tuesday, June 3, 2008

    Connecting IPOPT, Part 2

    I intend to have OpenOpt<->IPOPT bridge (via Eric's pyipopt) till next OO release.

    However, currently it works for Linux only (and I'm certainly not the one who could try to make it cross-platform) and requires hand-turn of makefile, first of all related to paths (python and numpy directories); also, probably you'll have to add -llapack (provided lapack-dev installation, if you have message "undefined symbol @dswap_") and -lgfortran (if you have "/usr/lib/ undefined symbol: _gfortran_concat_string", mb it requires gfortran installation, if you haven't the one installed). For more details see comments here (somehow they are not mentioned in Eric's README file).

    So after the issues I have IPOPT working for me. Here's picture below. This one referrs to (from /examples) with modified h3: instead of
    I have taken
    (because, as I have noticed, IPOPT handles the constraint so badly that I thought I have bug(s) in IPOPT connection, and hunting for those ones took a long time for me, because that constraint is present in my other NLP tests involved). And (despite IPOPT work probably can be somehow enhances via ipopt.opt file options modification) this is another one proof that having several solvers (like OO provides) is always better than having a single one, even so famous as IPOPT, isn't it?