Answered question
This question has been answered.

Unanswered question
This question has not been answered yet.

Hi Folks,

I encountered numerical issues when solving my problem (single thread and dual simplex method is used, markowitz threshold is set to 0.99999, CPLEX 12.2). I queried the stats of my problem, everything seems okay

Variables : 7159 [Nneg: 266, Fix: 1, Binary: 6892]
Objective nonzeros : 7159
Linear constraints : 7772 [Less: 7149, Greater: 518, Equal: 105]
Nonzeros : 240342
RHS nonzeros : 7149
Variables : Min LB: 0.0000000 Max UB: 1.000000
Objective nonzeros : Min : 1.000000 Max : 1000.000
Linear constraints :
Nonzeros : Min : 1.000000 Max : 10.00000
RHS nonzeros : Min : 1.000000 Max : 10.00000

I really appreciate for any help. Thanks.
The model file in .sav format is also attached.

Hi Folks,

I encountered numerical issues when solving my problem (single thread and dual simplex method is used, markowitz threshold is set to 0.99999, CPLEX 12.2). I queried the stats of my problem, everything seems okay
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">Variables : 7159 [Nneg: 266, Fix: 1, Binary: 6892]
Objective nonzeros : 7159
Linear constraints : 7772 [Less: 7149, Greater: 518, Equal: 105]
Nonzeros : 240342
RHS nonzeros : 7149
Variables : Min LB: 0.0000000 Max UB: 1.000000
Objective nonzeros : Min : 1.000000 Max : 1000.000
Linear constraints :
Nonzeros : Min : 1.000000 Max : 10.00000
RHS nonzeros : Min : 1.000000 Max : 10.00000
</pre>

I really appreciate for any help. Thanks.
The model file in .sav format is also attached.

This is the accepted answer.
This is the accepted answer.

Also I checked the kappa value which also seems fine:

Condition number of basis = 8.5e+004

And the error message I got from CPLEX:

CPLEX Error 1256: Basis singular.

Also I checked the kappa value which also seems fine:
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">Condition number of basis = 8.5e+004
</pre>
And the error message I got from CPLEX:
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">CPLEX Error 1256: Basis singular.
</pre>

Also I checked the kappa value which also seems fine:
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">Condition number of basis = 8.5e+004
</pre>
And the error message I got from CPLEX:
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">CPLEX Error 1256: Basis singular.
</pre>

I don't know what's going on, but I can confirm the issue. I ran your file on CPLEX 12.4.0.1 with all default settings, except that I told it to collect kappa statistics at every node. About 11 minutes into the run, still at the root node, I got error 1256 (but the run continued). I aborted the run and was told that the problem was integer feasible (three solutions in the pool) and that 100% of the bases were stable (largest condition number so far 1.2136e+06).

Paul

Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)

I don't know what's going on, but I can confirm the issue. I ran your file on CPLEX 12.4.0.1 with all default settings, except that I told it to collect kappa statistics at every node. About 11 minutes into the run, still at the root node, I got error 1256 (but the run continued). I aborted the run and was told that the problem was integer feasible (three solutions in the pool) and that 100% of the bases were stable (largest condition number so far 1.2136e+06).

Paul

Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)

> Paul Rubin wrote:
> I don't know what's going on, but I can confirm the issue. I ran your file on CPLEX 12.4.0.1 with all default settings, except that I told it to collect kappa statistics at every node. About 11 minutes into the run, still at the root node, I got error 1256 (but the run continued). I aborted the run and was told that the problem was integer feasible (three solutions in the pool) and that 100% of the bases were stable (largest condition number so far 1.2136e+06).
>
> Paul
>
> Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)
Not only are the original model numerics OK, but the numerics of the presolved model are also
fine. Furthermore, the problem can be reproduced at the initial LP relaxation solve using either
the dual or primal simplex method. That means that the cuts CPLEX may add to the model are
not involved in the LP issues here.

I will take a closer look at this. Meanwhile, try running the model with the numerical
emphasis parameter turned on. At least for the initial LP relaxation solve, that seems
to help the dual simplex method significantly.

For future reference, here are a couple of things you can do
to get more information in a situation like this. First, set the MIP display parameter to 4, so
you can see the initial node LP solve output. Doing this with startalgorithm set to 2 to select
the dual simplex method reveals that the dual simplex method is definitely having some sort of
numerical trouble with the model, well before the final error termination:

Iteration: 58320 Dual objective = 34842.543124
Iteration: 58494 Dual objective = 34842.543123
Repairing basis singularity.
Dual 'id12171' fixed because of singularity.
Added to 1d columns superbasic list.
Dual 'id15941' fixed because of singularity.
Added to 1d columns superbasic list.
Iteration: 58595 Dual infeasibility = 12995993208.442230
Repairing basis singularity.
Dual 'id12159' fixed because of singularity.
Added to 1d columns superbasic list.
Iteration: 58601 Dual infeasibility = 249089148.585084
Iteration: 58701 Dual infeasibility = 1434077023757887.500000
Elapsed time = 187.90 sec. (59000 iterations).
Iteration: 59202 Dual infeasibility = 1424556877204855.750000
...

Iteration: 99048 Dual infeasibility = 0.000005
Iteration: 99102 Dual objective = 34857.884805
Iteration: 99202 Dual objective = 34847.413743
Iteration: 99303 Dual objective = 34847.061503
Iteration: 99465 Dual objective = 34843.331894
Repairing basis singularity.
Dual 'id10483' fixed because of singularity.
Dual 'id11723' fixed because of singularity.
Dual 'id13633' fixed because of singularity.
Dual 'id14397' fixed because of singularity.
Dual 'id15157' fixed because of singularity.
Dual 'id19261' fixed because of singularity.
Dual 'id19363' fixed because of singularity.
Dual 'id19651' fixed because of singularity.
Dual 'id20409' fixed because of singularity.
Added to 9d columns superbasic list.
Iteration: 99566 Dual infeasibility = 0.000475
Iteration: 99712 Dual infeasibility = 0.000006
Iteration: 99735 Dual objective = 34843.221766

Nodes Cuts/
Node Left Objective IInf Best Integer Best Bound ItCnt Gap

0+ 0 0.0000 0 ---

0+ 0 9700.0000 0 ---

Root node processing (before b&c):
Real time = 386.61
Parallel b&c, 4 threads:
Real time = 0.00
Sync time (average) = 0.00
Wait time (average) = 0.00
Total (root+branch&cut) = 386.61 sec.
You can also set the mip display parameter to 5 to see subsequent node LP solve output,
but that can often generate more output than you want to see, and is not needed in this case.

> Paul Rubin wrote:
> I don't know what's going on, but I can confirm the issue. I ran your file on CPLEX 12.4.0.1 with all default settings, except that I told it to collect kappa statistics at every node. About 11 minutes into the run, still at the root node, I got error 1256 (but the run continued). I aborted the run and was told that the problem was integer feasible (three solutions in the pool) and that 100% of the bases were stable (largest condition number so far 1.2136e+06).
>
> Paul
>
> Mathematicians are like Frenchmen: whenever you say something to them, they translate it into their own language, and at once it is something entirely different. (Goethe)
Not only are the original model numerics OK, but the numerics of the presolved model are also
fine. Furthermore, the problem can be reproduced at the initial LP relaxation solve using either
the dual or primal simplex method. That means that the cuts CPLEX may add to the model are
not involved in the LP issues here.

I will take a closer look at this. Meanwhile, try running the model with the numerical
emphasis parameter turned on. At least for the initial LP relaxation solve, that seems
to help the dual simplex method significantly.

For future reference, here are a couple of things you can do
to get more information in a situation like this. First, set the MIP display parameter to 4, so
you can see the initial node LP solve output. Doing this with startalgorithm set to 2 to select
the dual simplex method reveals that the dual simplex method is definitely having some sort of
numerical trouble with the model, well before the final error termination:

Iteration: 58320 Dual objective = 34842.543124
Iteration: 58494 Dual objective = 34842.543123
Repairing basis singularity.
Dual 'id12171' fixed because of singularity.
Added to 1d columns superbasic list.
Dual 'id15941' fixed because of singularity.
Added to 1d columns superbasic list.
Iteration: 58595 Dual infeasibility = 12995993208.442230
Repairing basis singularity.
Dual 'id12159' fixed because of singularity.
Added to 1d columns superbasic list.
Iteration: 58601 Dual infeasibility = 249089148.585084
Iteration: 58701 Dual infeasibility = 1434077023757887.500000
Elapsed time = 187.90 sec. (59000 iterations).
Iteration: 59202 Dual infeasibility = 1424556877204855.750000
...

Iteration: 99048 Dual infeasibility = 0.000005
Iteration: 99102 Dual objective = 34857.884805
Iteration: 99202 Dual objective = 34847.413743
Iteration: 99303 Dual objective = 34847.061503
Iteration: 99465 Dual objective = 34843.331894
Repairing basis singularity.
Dual 'id10483' fixed because of singularity.
Dual 'id11723' fixed because of singularity.
Dual 'id13633' fixed because of singularity.
Dual 'id14397' fixed because of singularity.
Dual 'id15157' fixed because of singularity.
Dual 'id19261' fixed because of singularity.
Dual 'id19363' fixed because of singularity.
Dual 'id19651' fixed because of singularity.
Dual 'id20409' fixed because of singularity.
Added to 9d columns superbasic list.
Iteration: 99566 Dual infeasibility = 0.000475
Iteration: 99712 Dual infeasibility = 0.000006
Iteration: 99735 Dual objective = 34843.221766

Nodes Cuts/
Node Left Objective IInf Best Integer Best Bound ItCnt Gap

0+ 0 0.0000 0 ---

0+ 0 9700.0000 0 ---

Root node processing (before b&c):
Real time = 386.61
Parallel b&c, 4 threads:
Real time = 0.00
Sync time (average) = 0.00
Wait time (average) = 0.00
Total (root+branch&cut) = 386.61 sec.
You can also set the mip display parameter to 5 to see subsequent node LP solve output,
but that can often generate more output than you want to see, and is not needed in this case.

Do bases with singularities not get counted when kappa statistics are accumulated? The kappa stats (100% stable) seem inconsistent with the singularity messages.

Do bases with singularities not get counted when kappa statistics are accumulated? The kappa stats (100% stable) seem inconsistent with the singularity messages.

> Paul Rubin wrote:
> Ed,
>
> Do bases with singularities not get counted when kappa statistics are accumulated? The kappa stats (100% stable) seem inconsistent with the singularity messages.
>
> Paul
The kappa statistics require a basis factorization for the kappa computation, regardless of whether
CPLEX computes kappa exactly or using an less expensive estimate. So, the kappa statistics do not
include singular bases, which can be viewed as having an infinite condition number.

Do bases with singularities not get counted when kappa statistics are accumulated? The kappa stats (100% stable) seem inconsistent with the singularity messages.

Moreover, the MIP kappa statistics only include the final LP bases. Hitting singular bases during the simplex solve from which CPLEX was able to recover does not matter. And in fact, this is fine, because if CPLEX comes up in the end with a stable basis that is primal and dual feasible, then the path for reaching this basis is irrelevant (except that intermediate singular bases can increase the solve time).

Moreover, the MIP kappa statistics only include the final LP bases. Hitting singular bases during the simplex solve from which CPLEX was able to recover does not matter. And in fact, this is fine, because if CPLEX comes up in the end with a stable basis that is primal and dual feasible, then the path for reaching this basis is irrelevant (except that intermediate singular bases can increase the solve time).

> jimzhang wrote:
> Yes, the intermediate singular bases did increase the solve time and from my observation, the increase is significant for this model.

Are you saying you still get intermediate singular bases even if you turn on CPLEX's numerical emphasis?

> jimzhang wrote:
> Yes, the intermediate singular bases did increase the solve time and from my observation, the increase is significant for this model.

Are you saying you still get intermediate singular bases even if you turn on CPLEX's numerical emphasis?

Yes, here is the log for iterations after I turn on CPLEX's numerical emphasis (# of threads is set to 1 and I am using 12.2.0.2)
<pre class="jive-pre">
New value
for extreme numerical caution emphasis: yes
</pre>

> jimzhang wrote:
> Yes, the intermediate singular bases did increase the solve time and from my observation, the increase is significant for this model.

Are you saying you still get intermediate singular bases even if you turn on CPLEX's numerical emphasis?

And I have some other cases with different inputs but the same model which could not be solved even after turning on numerical emphasis. Is there any email box I could send them to? Thanks.

And I have some other cases with different inputs but the same model which could not be solved even after turning on numerical emphasis. Is there any email box I could send them to? Thanks.

> jimzhang wrote:
> And I have some other cases with different inputs but the same model which could not be solved even after turning on numerical emphasis. Is there any email box I could send them to? Thanks.
If you gzip them you could upload them to this forum, assuming they are of similar size to the one that you previously sent.

Meanwhile, we did look into the model that you already sent, and we confirmed that it has some bases that appear to have very high condition numbers despite the benign
coefficients in the constraint matrix. For example, take the attached SAV file,
which comes from the LP relaxation of the presolved model of the SAV file you previously updated. Read it into CPLEX, set a simplex iteration limit of 0 and
run the primopt command. The resulting solution has huge values and a huge condition
number:

CPLEX> d sol qu
Maximum bound infeasibility = 5.89546e+21
Maximum reduced-cost infeasibility = 3.74011e+24
Maximum Ax-b residual = 1.9455e+23
Maximum c-B'pi residual = 3.73668e+24
Maximum |x| = 5.72207e+21
Maximum |slack| = 5.89546e+21
Maximum |pi| = 1.13337e+23
Maximum |red-cost| = 3.74011e+24
Condition number of unscaled basis = 1.0e+75
This is one of the intermediate bases that CPLEX encountered, so that explains
the singular basis messages you saw. I had a look at the solution values that were
large and tried to use them to understand why a basis might have a huge condition
number like this. But, unfortunately, I was not successful. Perhaps with your
knowledge of your model you can do likewise and shed some light on this. In other
words, look at the variables with large solution values and the constraints they
intersect, and see if you can explain why such large values could arise.

Otherwise, if you have smaller models that reproduce this behavior, those might
help us as well. Also, an explanation of the model might help as well.

> jimzhang wrote:
> And I have some other cases with different inputs but the same model which could not be solved even after turning on numerical emphasis. Is there any email box I could send them to? Thanks.
If you gzip them you could upload them to this forum, assuming they are of similar size to the one that you previously sent.

Meanwhile, we did look into the model that you already sent, and we confirmed that it has some bases that appear to have very high condition numbers despite the benign
coefficients in the constraint matrix. For example, take the attached SAV file,
which comes from the LP relaxation of the presolved model of the SAV file you previously updated. Read it into CPLEX, set a simplex iteration limit of 0 and
run the primopt command. The resulting solution has huge values and a huge condition
number:

CPLEX> d sol qu
Maximum bound infeasibility = 5.89546e+21
Maximum reduced-cost infeasibility = 3.74011e+24
Maximum Ax-b residual = 1.9455e+23
Maximum c-B'pi residual = 3.73668e+24
Maximum |x| = 5.72207e+21
Maximum |slack| = 5.89546e+21
Maximum |pi| = 1.13337e+23
Maximum |red-cost| = 3.74011e+24
Condition number of unscaled basis = 1.0e+75
This is one of the intermediate bases that CPLEX encountered, so that explains
the singular basis messages you saw. I had a look at the solution values that were
large and tried to use them to understand why a basis might have a huge condition
number like this. But, unfortunately, I was not successful. Perhaps with your
knowledge of your model you can do likewise and shed some light on this. In other
words, look at the variables with large solution values and the constraints they
intersect, and see if you can explain why such large values could arise.

Otherwise, if you have smaller models that reproduce this behavior, those might
help us as well. Also, an explanation of the model might help as well.

> jimzhang wrote:
> And I have some other cases with different inputs but the same model which could not be solved even after turning on numerical emphasis. Is there any email box I could send them to? Thanks.
If you gzip them you could upload them to this forum, assuming they are of similar size to the one that you previously sent.

Meanwhile, we did look into the model that you already sent, and we confirmed that it has some bases that appear to have very high condition numbers despite the benign
coefficients in the constraint matrix. For example, take the attached SAV file,
which comes from the LP relaxation of the presolved model of the SAV file you previously updated. Read it into CPLEX, set a simplex iteration limit of 0 and
run the primopt command. The resulting solution has huge values and a huge condition
number:

CPLEX> d sol qu
Maximum bound infeasibility = 5.89546e+21
Maximum reduced-cost infeasibility = 3.74011e+24
Maximum Ax-b residual = 1.9455e+23
Maximum c-B'pi residual = 3.73668e+24
Maximum |x| = 5.72207e+21
Maximum |slack| = 5.89546e+21
Maximum |pi| = 1.13337e+23
Maximum |red-cost| = 3.74011e+24
Condition number of unscaled basis = 1.0e+75
This is one of the intermediate bases that CPLEX encountered, so that explains
the singular basis messages you saw. I had a look at the solution values that were
large and tried to use them to understand why a basis might have a huge condition
number like this. But, unfortunately, I was not successful. Perhaps with your
knowledge of your model you can do likewise and shed some light on this. In other
words, look at the variables with large solution values and the constraints they
intersect, and see if you can explain why such large values could arise.

Otherwise, if you have smaller models that reproduce this behavior, those might
help us as well. Also, an explanation of the model might help as well.

I tried to read the 17459.sav, however, CPLEX gave me this error message

CPLEX> read C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cplex\bin\x86_w
in32\17459.sav
CPLEX Error 1560: File 'C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cp
lex\bin\x86_win32\17459.sav' is not a SAV file.

Have you any idea regarding this?

Thanks.

Hi Ed,

I tried to read the 17459.sav, however, CPLEX gave me this error message
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">CPLEX> read C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cplex\bin\x86_w
in32\17459.sav
CPLEX Error 1560: File 'C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cp
lex\bin\x86_win32\17459.sav' is not a SAV file.
</pre>

I tried to read the 17459.sav, however, CPLEX gave me this error message
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">CPLEX> read C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cplex\bin\x86_w
in32\17459.sav
CPLEX Error 1560: File 'C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cp
lex\bin\x86_win32\17459.sav' is not a SAV file.
</pre>

> jimzhang wrote:
> Hi Ed,
>
> I tried to read the 17459.sav, however, CPLEX gave me this error message
>

> CPLEX> read C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cplex\bin\x86_w
> in32\17459.sav
> CPLEX Error 1560: File 'C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cp
> lex\bin\x86_win32\17459.sav' is not a SAV file.
>

>
> Have you any idea regarding this?
>
> Thanks.

Jim,
The issue here is that I did my investigation with a more recent version of
CPLEX. We made some changes to SAV format starting with CPLEX 12.3 to support
large numbers of nonzeros. While CPLEX 12.3 and later can read in SAV files generated
from earlier versions of CPLEX, the reverse is not true.
So, if you have access to 12.3 or later, use that. If not, let me know, and I will generate the corresponding SAV file that will work with 12.2.

> jimzhang wrote:
> Hi Ed,
>
> I tried to read the 17459.sav, however, CPLEX gave me this error message
>
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">> CPLEX> read C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cplex\bin\x86_w
> in32\17459.sav
> CPLEX Error 1560: File 'C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cp
> lex\bin\x86_win32\17459.sav' is not a SAV file.
>
</pre>
>
> Have you any idea regarding this?
>
> Thanks.

Jim,
The issue here is that I did my investigation with a more recent version of
CPLEX. We made some changes to SAV format starting with CPLEX 12.3 to support
large numbers of nonzeros. While CPLEX 12.3 and later can read in SAV files generated
from earlier versions of CPLEX, the reverse is not true.
So, if you have access to 12.3 or later, use that. If not, let me know, and I will generate the corresponding SAV file that will work with 12.2.

> jimzhang wrote:
> Hi Ed,
>
> I tried to read the 17459.sav, however, CPLEX gave me this error message
>
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">> CPLEX> read C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cplex\bin\x86_w
> in32\17459.sav
> CPLEX Error 1560: File 'C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cp
> lex\bin\x86_win32\17459.sav' is not a SAV file.
>
</pre>
>
> Have you any idea regarding this?
>
> Thanks.

Jim,
The issue here is that I did my investigation with a more recent version of
CPLEX. We made some changes to SAV format starting with CPLEX 12.3 to support
large numbers of nonzeros. While CPLEX 12.3 and later can read in SAV files generated
from earlier versions of CPLEX, the reverse is not true.
So, if you have access to 12.3 or later, use that. If not, let me know, and I will generate the corresponding SAV file that will work with 12.2.

Hi Ed, I do not have the version of 12.3. I really appreciate if you could export a 12.2 version for me. Many thanks.

I did a little more investigate after that. It seems that if I remove some of the terms from the objective functions (the ones with coefficients of 10). There would be no singular basis encountered. But the range of coefficients is just from 10 to 1000, which is quite normal...

Hi Ed, I do not have the version of 12.3. I really appreciate if you could export a 12.2 version for me. Many thanks.

I did a little more investigate after that. It seems that if I remove some of the terms from the objective functions (the ones with coefficients of 10). There would be no singular basis encountered. But the range of coefficients is just from 10 to 1000, which is quite normal...

> jimzhang wrote:
> Hi Ed, I do not have the version of 12.3. I really appreciate if you could export a 12.2 version for me. Many thanks.

I have attached a suitable gzipped SAV file. Read it in to 12.2, set an iteration
limit of 0, invoke either primopt or dualopt, then examine the solution quality
('dis solution quality'). If you can tell us anything about why this particular
basis might have a high condition number, that would help us a lot. Also, if you
are willing to let us give this file to a couple of academics who are interested
in ill conditioned problems, let me know.

>
> I did a little more investigate after that. It seems that if I remove some of the terms from the objective functions (the ones with coefficients of 10). There would be no singular basis encountered. But the range of coefficients is just from 10 to 1000, which is quite normal...

Agreed. However, while models with wide ranges of coefficients often result in
large basis condition numbers, that is not a necessary condition. Wide ranges
of coefficients tend to introduce more round off error in a finite precision computing
environment, which makes a model more susceptible to problems if it has bases with
high condition numbers. But, you can have ill conditioned models under perfect
precision with benign coefficients as well. For example, here is a matrix that
we encountered in some of our internal testing. It came from the ilaser0 model on
Mittelmann's QP test set. It's a square matrix of the form

All the coefficients are reasonable, and the matrix is even upper triangular.
Yet, this will cause trouble for numerous reasons:

1) Just looking at the determinant, we see that it is 6ˆ(-m) where m is the dimension of the matrix. So, this is essentially zero, and the matrix
is essentially singular despite the reasonable diagonal elements. Given that
the condition number can be interpreted as the reciprocal of the distance to
singularity of a matrix, this means that the matrix has a large condition number.

2) If you do the solve Bx_B = b with this matrix for any right hand side b, you can quickly see that it will generate really large values for x_B.

3) If you step through the pivoting operations to calculate the inverse of this basis matrix, you will see that the inverse indeed has large
values. Given that the condition number of a matrix is defined as product of the norms of the matrix and its inverse, this has a huge condition number as the dimension
increases. It's already large for just m = 20.
For this particular basis matrix, one could easily see that the basis matrix was
ill conditioned. I suspect your model is similar in some way, but the nature of the large condition number in the basis in the attached SAV file is not as easy to see as with the example above. I was hoping with your knowledge of the model, you might
be able to either explain the corresponding behavior in your model, or shed some light
on the constraints and variables that you think are involved.

> jimzhang wrote:
> Hi Ed, I do not have the version of 12.3. I really appreciate if you could export a 12.2 version for me. Many thanks.

I have attached a suitable gzipped SAV file. Read it in to 12.2, set an iteration
limit of 0, invoke either primopt or dualopt, then examine the solution quality
('dis solution quality'). If you can tell us anything about why this particular
basis might have a high condition number, that would help us a lot. Also, if you
are willing to let us give this file to a couple of academics who are interested
in ill conditioned problems, let me know.

>
> I did a little more investigate after that. It seems that if I remove some of the terms from the objective functions (the ones with coefficients of 10). There would be no singular basis encountered. But the range of coefficients is just from 10 to 1000, which is quite normal...

Agreed. However, while models with wide ranges of coefficients often result in
large basis condition numbers, that is not a necessary condition. Wide ranges
of coefficients tend to introduce more round off error in a finite precision computing
environment, which makes a model more susceptible to problems if it has bases with
high condition numbers. But, you can have ill conditioned models under perfect
precision with benign coefficients as well. For example, here is a matrix that
we encountered in some of our internal testing. It came from the ilaser0 model on
Mittelmann's QP test set. It's a square matrix of the form
<pre class="jive-pre">
1/6 4/6 1/6 1/6 4/6 1/6 1/6 4/6 1/6 1/6 4/6 1/6 ... ... 1/6 4/6 1/6 1/6 4/6 1/6
</pre>

All the coefficients are reasonable, and the matrix is even upper triangular.
Yet, this will cause trouble for numerous reasons:

1) Just looking at the determinant, we see that it is 6ˆ(-m) where m is the dimension of the matrix. So, this is essentially zero, and the matrix
is essentially singular despite the reasonable diagonal elements. Given that
the condition number can be interpreted as the reciprocal of the distance to
singularity of a matrix, this means that the matrix has a large condition number.

2) If you do the solve Bx_B = b with this matrix for any right hand side b, you can quickly see that it will generate really large values for x_B.

3) If you step through the pivoting operations to calculate the inverse of this basis matrix, you will see that the inverse indeed has large
values. Given that the condition number of a matrix is defined as product of the norms of the matrix and its inverse, this has a huge condition number as the dimension
increases. It's already large for just m = 20.
For this particular basis matrix, one could easily see that the basis matrix was
ill conditioned. I suspect your model is similar in some way, but the nature of the large condition number in the basis in the attached SAV file is not as easy to see as with the example above. I was hoping with your knowledge of the model, you might
be able to either explain the corresponding behavior in your model, or shed some light
on the constraints and variables that you think are involved.

Hi Ed, I do not have the version of 12.3. I really appreciate if you could export a 12.2 version for me. Many thanks.

I did a little more investigate after that. It seems that if I remove some of the terms from the objective functions (the ones with coefficients of 10). There would be no singular basis encountered. But the range of coefficients is just from 10 to 1000, which is quite normal...

> jimzhang wrote:
> Hi Ed, I do not have the version of 12.3. I really appreciate if you could export a 12.2 version for me. Many thanks.

I have attached a suitable gzipped SAV file. Read it in to 12.2, set an iteration
limit of 0, invoke either primopt or dualopt, then examine the solution quality
('dis solution quality'). If you can tell us anything about why this particular
basis might have a high condition number, that would help us a lot. Also, if you
are willing to let us give this file to a couple of academics who are interested
in ill conditioned problems, let me know.

>
> I did a little more investigate after that. It seems that if I remove some of the terms from the objective functions (the ones with coefficients of 10). There would be no singular basis encountered. But the range of coefficients is just from 10 to 1000, which is quite normal...

Agreed. However, while models with wide ranges of coefficients often result in
large basis condition numbers, that is not a necessary condition. Wide ranges
of coefficients tend to introduce more round off error in a finite precision computing
environment, which makes a model more susceptible to problems if it has bases with
high condition numbers. But, you can have ill conditioned models under perfect
precision with benign coefficients as well. For example, here is a matrix that
we encountered in some of our internal testing. It came from the ilaser0 model on
Mittelmann's QP test set. It's a square matrix of the form

All the coefficients are reasonable, and the matrix is even upper triangular.
Yet, this will cause trouble for numerous reasons:

1) Just looking at the determinant, we see that it is 6ˆ(-m) where m is the dimension of the matrix. So, this is essentially zero, and the matrix
is essentially singular despite the reasonable diagonal elements. Given that
the condition number can be interpreted as the reciprocal of the distance to
singularity of a matrix, this means that the matrix has a large condition number.

2) If you do the solve Bx_B = b with this matrix for any right hand side b, you can quickly see that it will generate really large values for x_B.

3) If you step through the pivoting operations to calculate the inverse of this basis matrix, you will see that the inverse indeed has large
values. Given that the condition number of a matrix is defined as product of the norms of the matrix and its inverse, this has a huge condition number as the dimension
increases. It's already large for just m = 20.
For this particular basis matrix, one could easily see that the basis matrix was
ill conditioned. I suspect your model is similar in some way, but the nature of the large condition number in the basis in the attached SAV file is not as easy to see as with the example above. I was hoping with your knowledge of the model, you might
be able to either explain the corresponding behavior in your model, or shed some light
on the constraints and variables that you think are involved.

> jimzhang wrote:
> Hi Ed, I do not have the version of 12.3. I really appreciate if you could export a 12.2 version for me. Many thanks.

I have attached a suitable gzipped SAV file. Read it in to 12.2, set an iteration
limit of 0, invoke either primopt or dualopt, then examine the solution quality
('dis solution quality'). If you can tell us anything about why this particular
basis might have a high condition number, that would help us a lot. Also, if you
are willing to let us give this file to a couple of academics who are interested
in ill conditioned problems, let me know.

>
> I did a little more investigate after that. It seems that if I remove some of the terms from the objective functions (the ones with coefficients of 10). There would be no singular basis encountered. But the range of coefficients is just from 10 to 1000, which is quite normal...

Agreed. However, while models with wide ranges of coefficients often result in
large basis condition numbers, that is not a necessary condition. Wide ranges
of coefficients tend to introduce more round off error in a finite precision computing
environment, which makes a model more susceptible to problems if it has bases with
high condition numbers. But, you can have ill conditioned models under perfect
precision with benign coefficients as well. For example, here is a matrix that
we encountered in some of our internal testing. It came from the ilaser0 model on
Mittelmann's QP test set. It's a square matrix of the form
<pre class="jive-pre">
1/6 4/6 1/6 1/6 4/6 1/6 1/6 4/6 1/6 1/6 4/6 1/6 ... ... 1/6 4/6 1/6 1/6 4/6 1/6
</pre>

All the coefficients are reasonable, and the matrix is even upper triangular.
Yet, this will cause trouble for numerous reasons:

1) Just looking at the determinant, we see that it is 6ˆ(-m) where m is the dimension of the matrix. So, this is essentially zero, and the matrix
is essentially singular despite the reasonable diagonal elements. Given that
the condition number can be interpreted as the reciprocal of the distance to
singularity of a matrix, this means that the matrix has a large condition number.

2) If you do the solve Bx_B = b with this matrix for any right hand side b, you can quickly see that it will generate really large values for x_B.

3) If you step through the pivoting operations to calculate the inverse of this basis matrix, you will see that the inverse indeed has large
values. Given that the condition number of a matrix is defined as product of the norms of the matrix and its inverse, this has a huge condition number as the dimension
increases. It's already large for just m = 20.
For this particular basis matrix, one could easily see that the basis matrix was
ill conditioned. I suspect your model is similar in some way, but the nature of the large condition number in the basis in the attached SAV file is not as easy to see as with the example above. I was hoping with your knowledge of the model, you might
be able to either explain the corresponding behavior in your model, or shed some light
on the constraints and variables that you think are involved.

> jimzhang wrote:
> Hi Ed, I do not have the version of 12.3. I really appreciate if you could export a 12.2 version for me. Many thanks.

I have attached a suitable gzipped SAV file. Read it in to 12.2, set an iteration
limit of 0, invoke either primopt or dualopt, then examine the solution quality
('dis solution quality'). If you can tell us anything about why this particular
basis might have a high condition number, that would help us a lot. Also, if you
are willing to let us give this file to a couple of academics who are interested
in ill conditioned problems, let me know.

>
> I did a little more investigate after that. It seems that if I remove some of the terms from the objective functions (the ones with coefficients of 10). There would be no singular basis encountered. But the range of coefficients is just from 10 to 1000, which is quite normal...

Agreed. However, while models with wide ranges of coefficients often result in
large basis condition numbers, that is not a necessary condition. Wide ranges
of coefficients tend to introduce more round off error in a finite precision computing
environment, which makes a model more susceptible to problems if it has bases with
high condition numbers. But, you can have ill conditioned models under perfect
precision with benign coefficients as well. For example, here is a matrix that
we encountered in some of our internal testing. It came from the ilaser0 model on
Mittelmann's QP test set. It's a square matrix of the form
<pre class="jive-pre">
1/6 4/6 1/6 1/6 4/6 1/6 1/6 4/6 1/6 1/6 4/6 1/6 ... ... 1/6 4/6 1/6 1/6 4/6 1/6
</pre>

All the coefficients are reasonable, and the matrix is even upper triangular.
Yet, this will cause trouble for numerous reasons:

1) Just looking at the determinant, we see that it is 6ˆ(-m) where m is the dimension of the matrix. So, this is essentially zero, and the matrix
is essentially singular despite the reasonable diagonal elements. Given that
the condition number can be interpreted as the reciprocal of the distance to
singularity of a matrix, this means that the matrix has a large condition number.

2) If you do the solve Bx_B = b with this matrix for any right hand side b, you can quickly see that it will generate really large values for x_B.

3) If you step through the pivoting operations to calculate the inverse of this basis matrix, you will see that the inverse indeed has large
values. Given that the condition number of a matrix is defined as product of the norms of the matrix and its inverse, this has a huge condition number as the dimension
increases. It's already large for just m = 20.
For this particular basis matrix, one could easily see that the basis matrix was
ill conditioned. I suspect your model is similar in some way, but the nature of the large condition number in the basis in the attached SAV file is not as easy to see as with the example above. I was hoping with your knowledge of the model, you might
be able to either explain the corresponding behavior in your model, or shed some light
on the constraints and variables that you think are involved.

Hi Ed,
Thanks for your explanations. I did some further investigation and found that there is a pattern of constraint in my model (in the attached file), if I dis-activate it, the model will be solved with no numerical issues and the numerical issue will be raised up if I activate it.

I would like to populate a couple of constraints of a small case for this pattern of constraints on the purpose of illustration, let's say t=1,2,3, {Ln} = {1,2,3}

But I am not sure what the internal coefficient matrix in CPLEX looks like (after adding slack variables, and presolving?) Hope it helpful. Thanks.

I would like to populate a couple of constraints of a small case for this pattern of constraints on the purpose of illustration, let's say t=1,2,3, {Ln} = {1,2,3}
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">y_1_1 + y_2_2 + y_3_2 <= 1
y_2_1 + y_1_2 + y_3_2 <= 1
y_3_1 + y_1_2 + y_2_2 <= 1
y_1_2 + y_2_3 + y_3_3 <= 1
y_2_2 + y_1_3 + y_3_3 <= 1
y_3_2 + y_1_3 + y_2_3 <= 1
</pre>
The coefficient matrix would be (if I am correct)
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">1,0,0,1,1,0,0,0,0
0,1,0,1,0,1,0,0,0
0,0,1,1,1,1,0,0,0
0,0,0,1,0,0,0,1,1
0,0,0,0,1,0,1,0,1
0,0,0,0,0,1,1,1,0
</pre>
But I am not sure what the internal coefficient matrix in CPLEX looks like (after adding slack variables, and presolving?) Hope it helpful. Thanks.

I did see some of the y variables taking ridiculously large values (either positive or negative) in the file you provided, so is possible that some of the y variables happening to be in the basis and the basis impacted by the pattern of constraints I showed in the last thread has some determinant close to 0, as a result, they are taking ridiculous values? Thanks

Actually, I found by the first formulation I provided previously could satisfy these relevant formulations automatically. But I still include it in the model file. Would CPLEX remove this relevant formulation in the pre-solving? if not, would this be an issue?

I also have another pattern of constraints which should be relevant to this issue

Relevant formulations
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">y_1_1 + y_2_1 + y_3_1 <= 1
y_1_2 + y_2_2 + y_3_2 <= 1
y_1_3 + y_2_3 + y_3_3 <= 1
</pre>
Actually, I found by the first formulation I provided previously could satisfy these relevant formulations automatically. But I still include it in the model file. Would CPLEX remove this relevant formulation in the pre-solving? if not, would this be an issue?

> jimzhang wrote:
> Hi Ed,
>
> I tried to read the 17459.sav, however, CPLEX gave me this error message
>
<pre class="java dw" data-editor-lang="java" data-pbcklang="java" dir="ltr">> CPLEX> read C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cplex\bin\x86_w
> in32\17459.sav
> CPLEX Error 1560: File 'C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cp
> lex\bin\x86_win32\17459.sav' is not a SAV file.
>
</pre>
>
> Have you any idea regarding this?
>
> Thanks.

Jim,
The issue here is that I did my investigation with a more recent version of
CPLEX. We made some changes to SAV format starting with CPLEX 12.3 to support
large numbers of nonzeros. While CPLEX 12.3 and later can read in SAV files generated
from earlier versions of CPLEX, the reverse is not true.
So, if you have access to 12.3 or later, use that. If not, let me know, and I will generate the corresponding SAV file that will work with 12.2.

> EdKlotz wrote:
> > jimzhang wrote:
> > Hi Ed,
> >
> > I tried to read the 17459.sav, however, CPLEX gave me this error message
> >

> > CPLEX> read C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cplex\bin\x86_w > > in32\17459.sav > > CPLEX Error 1560: File
'C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cp > > lex\bin\x86_win32\17459.sav
' is not a SAV file. > >

> >
> > Have you any idea regarding this?
> >
> > Thanks.
>
> Jim,
> The issue here is that I did my investigation with a more recent version of
> CPLEX. We made some changes to SAV format starting with CPLEX 12.3 to support
> large numbers of nonzeros. While CPLEX 12.3 and later can read in SAV files generated
> from earlier versions of CPLEX, the reverse is not true.
> So, if you have access to 12.3 or later, use that. If not, let me know, and I will generate the corresponding SAV file that will work with 12.2.
Jim, if you have any info regarding the subset of constraints and variables that create the large condition numbers, let us know. Otherwise, if we can keep the 17459.sav.gz file (and also the original model) and add it to our R&D test set, let us know; that might help us add some future features to CPLEX that would provide users more info on any ill conditioning in their models.

Ed

> EdKlotz wrote:
> > jimzhang wrote:
> > Hi Ed,
> >
> > I tried to read the 17459.sav, however, CPLEX gave me this error message
> >
<pre class="jive-pre">
> > CPLEX> read C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cplex\bin\x86_w > > in32\17459.sav > > CPLEX Error 1560: File
'C:\cc_view\yd_tools\orapps\Tools\ILOG\Cplex\12.2.0.2\cp > > lex\bin\x86_win32\17459.sav
' is not a SAV file. > >
</pre>
> >
> > Have you any idea regarding this?
> >
> > Thanks.
>
> Jim,
> The issue here is that I did my investigation with a more recent version of
> CPLEX. We made some changes to SAV format starting with CPLEX 12.3 to support
> large numbers of nonzeros. While CPLEX 12.3 and later can read in SAV files generated
> from earlier versions of CPLEX, the reverse is not true.
> So, if you have access to 12.3 or later, use that. If not, let me know, and I will generate the corresponding SAV file that will work with 12.2.
Jim, if you have any info regarding the subset of constraints and variables that create the large condition numbers, let us know. Otherwise, if we can keep the 17459.sav.gz file (and also the original model) and add it to our R&D test set, let us know; that might help us add some future features to CPLEX that would provide users more info on any ill conditioning in their models.