From a log file:
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
MOSEK Warning 700 : 8 zero elements are specified in sparse input data.
First: issuing this message one time is more than enough.
I suspect this is related to a very small value in the GAMS model, below some a[i,j] tolerance. As GAMS will not export zero coefficients, a strict reading of these messages would mean there is a bug somewhere. So lets hope these error messages are somewhat poorly formulated and indeed this a matter of small values being present in the model.
Formulating correct and succinct error messages is very important (but often underestimated by software developers, myself included). They provide feedback to user when it really matters: when something is wrong and the user is most likely confused.
These messages will be improved in the upcoming MOSEK v6. It will say in which row or column of A the zeros are located.
ReplyDeleteYou are welcome to send the model to support@mosek.com and I shall check if v6 reports it better.
Also it is possible for GAMS to customize the GAMS/MOSEK interface to get it to report the errors in the way they like. It might that these messages does not make sense in a GAMS setting for instance and hence should turned off.
Therefore, I will also suggest you send your comments to the GAMS support at support@gams.com.
Regards
Erling from MOSEK.
Thanks for the feedback. I tried with a small model (this was a large complex thing):
ReplyDeletevariable x,z; equation e;
e.. z =g= 1.0e-15*x;
x.lo=1;
model m/all/;
solve m minimizing z using lp;
This shows the error once so it looks related to small values instead of only real zeroes. The big model has some linearizations which may cause small coefficients.
Putting small numbers like 1.0e-15 is not recommended. They may be innocent but they can also cause a lot of problems because we have hard time of figuring out what is zero and what is not.
ReplyDeleteFor instance if you have the constraint
1.0 x + 1.0e-15 y = 1
as part of large model. It might be very hard to find scaling that makes it nicely scaled.
My line of thinking is that when linearizing a sanity check might be useful. I.e. remove small elements and check for large elements.
My first reaction was "the modeler should not deal with such tolerances, that is the responsibility of the solver". When equations are generated by algorithms, we can expect these small numbers. Should the modeler apply tolerances and change the input or should the solver do that? Large values are often a slightly different story: they usually only happen in poorly scaled models.
ReplyDelete