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 pywrapper.so 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)

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.

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/nlp_bench2.py for N=100). Usually OO v0.17 ralg consumes about 5-10% objFunc and 3-5% nonlinear constraints evaluations greater.

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.

Example:

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.

numpy-related bug

If you have encountered problems (during using OO) like the one:
[...]

  File "/usr/lib/python2.5/site-packages/scipy/sparse/base.py", line
139, in spmatrix
  @deprecate
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.