Wjy does A apparently need to have at least one row in snsolve?

[Mark L. Stone]

I am trying to understand why A (linear inequality matrix) apparently needs to have at least one row in snsolve, which is the fmincon style front end for SNOPT 7.4-1.2. I thought it seemed strange that A and b are not varargin, and indeed that the 2nd dimension of A is used as n = number of variables.

Calling snsolve with A and b both being [] results in
Error using snoptmex
xmul has incorrect row dimension 0. Should be length <value of n>
Error in snsolve (line 116)
[x,F,exitflag,xmul,Fmul] = snoptmex( solveopt, x0, ...

where <value of n> is the value of n.

I can work around it by using zeros(1,n) for A, and 0 for b, and that executes without error. But why is that necessary?

Thanks.

[Elizabeth Wong]

snsolve is mimicking fmincon's syntax and call structure. I think "x
= fmincon(fun,x0,A,b)" is the shortest command to call fmincon. Both
fmincon and snopt are constrained optimization solvers so I think it
makes sense that they expect at least one constraints of some kind.

However, you have pointed out a bug. snsolve is trying to determine
the number of variables in the problem from A. I'll fix this and
update the files asap.

--Elizabeth

> --
> You received this message because you are subscribed to the Google Groups "SNOPT" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to snopt+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Mark L. Stone]

Elizabeth,

You are indeed correct that fmincon requires at least one constraint. However, that could be lower bound or upper bound constraints (not necessarily even finite, so not really constraining). fmincon does require A and b, however, if non-empty Aeq and beq, or lb, or ub (even if lb or ub are not finite) are provided, fmincon accepts the problem even if A and b are []. Note that knitromatlab accepts all the forms which fmincon does, plus knitromatlab(fun,xo), i.e., A and b need not be provided at all.

I personally think that the knitromatlab way of doing it is better than the fmincon way. But in any event, A and b should be allowed to be []. If you were to use the knitromatlab convention, then A and b should be varargin.

Thanks.

[Elizabeth Wong]

Hi Mark,

I should've said it explicitly in my reply, but I agree that A and b
should be allowed to be []. The bug I'm trying to fix is what is
preventing that.

--Elizabeth

On Sun, Jun 14, 2015 at 5:22 AM, 'Mark L. Stone' via SNOPT

[Mark L. Stone]

Elizabeth,

It sounds like you are aware of the bug(s), and now "just" have to figure out how to fix it (them). Nevertheless, see https://groups.google.com/forum/#!topic/yalmip/FgZpfvKZ4MI for some bugs discovered while calling SNOPT from YALMIP. Perhaps these are die to the bug(s) you already know about.

As for why SNOPT declares apparent infeasibility in the 3 SOCPs in yalmiptest('snopt') when other solvers (claim to) solve them?

[Elizabeth Wong]

Mark,
The bug has been fixed. The issue you pointed out with empty A and b
has also been taken care of. Our files have been updated so you can
go and grab a new copy now.

On Mon, Jun 15, 2015 at 8:07 AM, 'Mark L. Stone' via SNOPT

[Mark L. Stone]

Thanks Elizabeth.

I see that snsolve now determines n = number of variables based on x0, which makes sense.

I hope I need a new MEX file (otherwise the bugs haven't been fixed). I will report back whether all the bug manifestations I know of have been fixed once I get the new MEX file.

[Mark L. Stone]

Elizabeth,

There appears to be at least one bug left, and happened with empty A and b.

[x,fval,exitflag,lambda]=snsolve(@(X)rosenbrockwrapper_m(X,1e2),[-1.2;1],[1 1],[300],[],[],[-1e2;-1e2],[1e2;1e2])
executes without error.

[x,fval,exitflag,lambda]=snsolve(@(X)rosenbrockwrapper_m(X,1e2),[-1.2;1],[],[],[],[],[-1e2;-1e2],[1e2;1e2])
Error using snoptmex
A has incorrect column dimension 0. Should be length 1
Error in snsolve (line 122)

[x,F,exitflag,xmul,Fmul] = snoptmex( solveopt, x0, ...

function [f,g] = rosenbrockwrapper_m(X,m)
f = objective_function_rosenbrock_m(X,m);
g = objective_gradient_rosenbrock_m(X,m);
end

function out = objective_function_rosenbrock_m(X,m)
out = m*(X(2)-X(1)^2)^2+(1-X(1))^2;

function [gradient] = objective_gradient_rosenbrock_m(X,m)
diff_X1=-4*m*(X(2)-X(1)^2)*X(1)-2+2*X(1);
diff_X2=2*m*(X(2)-X(1)^2);
gradient=[diff_X1; diff_X2];
end

Also, yalmiptest('snopt') incorrectly reports infeasibility for the 3 SOCPs in yalmiptest. Per YALMIP developer Johan (who was not sure whether bug is on YALMIP end or on SNOPT end) on June 15 (prior to new build on June 16), in https://groups.google.com/forum/#!topic/yalmip/FgZpfvKZ4MI

snopt doesn't like the quadratic form of the socp constraints (which yalmip uses as callbacks when nonlinear solver is used)

sdpvar x t
optimize(cone([1-x;x],t),t,sdpsettings('solver','fmincon'))
optimize([t >=0, x^2 + (1-x)^2 <= t^2],t,sdpsettings('solver','fmincon'))
optimize([t >=0, x^2 + (1-x)^2 <= t^2],t,sdpsettings('solver','snopt'))

considering the current bugs, I cannot judge if this is due to algorithmic reasons in snopt, bugs in snopt, or bugs in yalmip (which reuses the same callback machinery for fmincon and snopt)

[Mark L. Stone]

Using snsolve, I get some type of error message or crash in MATLAB with any nonlcon, whether with a non-empty or empty A and b. That includes nonlcon files with non-empty c and empty ceq, empty c and non-empty ceq, and non-empty c and nonempty ceq.