Different results on Windows vs. Linux

[Din]

Hi,
I am running ILOG AMPL 10.000 on both my local machine (Windows) and a
Linux Server. I am using a commands file to test a cutting plane
scheme. When I run the same command file with the same model and data
I am getting different results on Windows and Linux: In windows my
run finishes in 19 iterations, while in Linux, the run finishes in 35.
I am also testing the feasibility of an intermediate problem during
the iterative process. AMPL-CPLEX on Windows reports feasibility on
all instances, where as on Linux there are some cases when the problem
is reported infeasible.

I am using the following options in my commands file.
option omit_zero_rows 1;
option cplex_options 'feasibility 1.0e-9 presolve 0';
option display_eps 0.000001;
#option presolve_eps 1e-8;
option presolve 0;

Could anyone shed some light?

Thanks!
Din

[Paul]

Different compilers on different hardware platforms introduce some
"minor" differences in floating-point arithmetic, enough to alter the
branching sequence in a MIP and the pivot sequence in an LP in some
cases. I think that Emilie Danna at CPLEX has documented this and
presented about it at conferences. That might account for some
differences in iteration count.

As far as feasibility v. infeasibility, if an LP/MIP has an ill-
conditioned constraint matrix, funny things can happen when it comes
to feasibility. Combine that with the platform issue above and it
might explain why you're seeing different conclusions about
feasibility on the two platforms (although I can't be sure that's it).

I take it the problem data is entered the same way on both platforms
(calculated from the same script, read from the same file, ...)?
Solving a problem using data generated within the AMPL model/script
(or by a calling program) and solving the same problem after writing
out the data/model (say to an MPS file) and reading it into a solver
can produce entirely different results if the matrix is ill-
conditioned, because write to file/read back causes a loss of
precision (at least if the file being written is text rather than
binary).

/Paul

[Din]

Hi Paul,
Thanks for your reply.
Yes, I am using the same data input/output format for both windows and
Linux - I am using a model file with 3 different models, a run file,
and a data file. I am making parameter assignments from one model's
solve as an input to another during the iterations using AMPL's 'let'
command. All problems are LP's.

Would it be of any help if I used Callable libraries/Concert
technology instead of making AMPL calls?

Thanks again
Din

[Paul]

On Nov 6, 10:33 pm, Din <dinakar.g...@gmail.com> wrote:
> Hi Paul,
> Thanks for your reply.
> Yes, I am using the same data input/output format for both windows and
> Linux - I am using a model file with 3 different models, a run file,
> and a data file. I am making parameter assignments from one model's
> solve as an input to another during the iterations using AMPL's 'let'
> command. All problems are LP's.
>
> Would it be of any help if I used Callable libraries/Concert
> technology instead of making AMPL calls?
>
> Thanks again
> Din
>

Possible but doubtful. You might try writing one of the intermediate
problems where Windows and Linux results were different to an MPS
file. Read it into CPLEX interactive solver, solve it, and see what
the condition number of the basis matrix is. If the matrix is ill-
conditioned (admittedly a relative judgment), you might investigate
whether you can reformulate the problem to have a nicer condition
matrix. (Besides the condition number of the final basis, you might
get signals of ill-conditioning if CPLEX refactors the basis
frequently or issues warnings along the way).

You're using the variables values from a solution to one problem to
modify the parameters of the next problem? When you said that
intermediate problems were reported feasible under Windows but
infeasible under Linux, did you confirm that the models being tested
were identical? If any of your LPs have multiple optimal solutions,
it's possible that you get different solutions on Windows and Linux
(both optimal, but different variable values) due to different pivot
sequences. That would lead to a divergence in the subsequent problems
(different coefficient matrices) and any cross-platform comparability
would be lost.

/Paul

[Din]

Paul, thanks again for your reply.
Yes, I am observing divergence of results after 5 iterations or so. As
you suggested, I wrote out an MPS file and fed it to CPLEX at the
iteration before I was getting infeasibility. CPLEX reported the
matrix condition number as 230.

Thanks

[Paul]

On Nov 9, 10:20 am, Din <dinakar.g...@gmail.com> wrote:
> Yes, I am observing divergence of results after 5 iterations or so. As
> you suggested, I wrote out an MPS file and fed it to CPLEX at the
> iteration before I was getting infeasibility. CPLEX reported the
> matrix condition number as 230.

That's a fairly high condition number, but I don't know if it is high
enough to produce numerical instability in the computations. You
might post a question about that on a CPLEX forum.

Regarding divergence of results, I take this to mean that the
solutions (and thus the coefficients of the subsequent problems) are
the same for four or five iterations, and then you get a difference in
the solution, which as I understand it will lead to different
coefficients in the next LP. At the first iteration where the LP
solutions differ, the LP being solved should be identical across
platforms. Are the resulting objective values the same (indicating
multiple optimal solutions), or are the objective values different
(indicating, I think, a numerical stability issue with the problem)?

/Paul

[Din]

Hi Paul,
The objective values are different across platforms.

Thanks

[Ali Baharev]

> iteration before I was getting infeasibility. CPLEX reported the
> matrix condition number as 230.

This is not that bad, it should tolerate much higher condition numbers.

But the condition number varies with each pivoting and I am afraid
your are not able to see those...

I do not understand your problem in details but its perfectly normal
to get different results in different software and hardware
environments.

Sorry i could not be more helpful.

Ali

[Paul]

On Nov 9, 12:16 pm, Ali Baharev <ali.baha...@gmail.com> wrote:

>
> I do not understand your problem in details but its perfectly normal
> to get different results in different software and hardware
> environments.

Some differences in precision are, I think, normal, and different
pivot sequences (or, in the case of a MIP, different node sequences)
are not uncommon. Getting a suboptimal solution for the problem on
one platform and an optimal solution on another (or having the problem
declared infeasible on one platform and not another) with the same
coefficients is not particularly normal, though. When I've seen this
in the past, the cause has been one of two things: problem data read
from text files in one case and computed in the other; or slight
differences in arithmetic between platforms together with a
numerically unstable problem (ill-conditioned matrix).

I agree that the final condition number doesn't look too horrible, but
as Ali said that's only the final one; no telling what cropped up
along the way. Din, you might want to try playing with feasibility
tolerances, or the Markowitz tolerance ('simplex tolerances markowitz'
in the interactive optimizer, parameter EpMark in the C++/Java APIs)
to see if you can induce consistent behavior. If fiddling with EpMark
gets the same solution on both platforms, I would consider that an
indication of numerical instability (which is often, but not always,
the result of poor scaling of the columns).

/Paul

[Ali Baharev]

>> I do not understand your problem in details but its perfectly normal
>> to get different results in different software and hardware
>> environments.

Sorry. I meant: it can happen and you should not be surprised.

Once, I had a screwy LP problem for which 5 different solvers gave 5
totally different solutions.

Even a slight change in the settings of the solver may cause strange
results for a given problem in a given software and hardware
environment.

> gets the same solution on both platforms, I would consider that an
> indication of numerical instability (which is often, but not always,
> the result of poor scaling of the columns).

By the way, can you send us your problem in mps or cplex lp format? I
could check if it is badly scaled or not.

Ali