[Ipopt] large quadratic problem - linear solver performance

[Ivo Stefanov]

Hello, 
  I am not sure if this is the right place to ask this as it seems to be purely related to the linear solver used, but let me give some background of what I am observing.  I am trying to solve the following (quadratic) problem:  
   Number of nonzeros in equality constraint Jacobian...:
 8978916  Number of nonzeros in inequality constraint Jacobian.:
 
378079  Number of nonzeros in Lagrangian Hessian.............:
 
 
9206  
  Total number of variables............................:
 
378696  
 
 
 
 
 
 
 
 
 
 
variables with only lower bounds:
 
338885  
 
 
 
 
 
 
 
 variables with lower and upper bounds:
 
 39177  
 
 
 
 
 
 
 
 
 
 
variables with only upper bounds:
 
 
 
 0  Total number of equality constraints.................:
 
 39757  Total number of inequality constraints...............:
 
338923  
 
 
 
 inequality constraints with only lower bounds:
 
 
 
 0  
 
inequality constraints with lower and upper bounds:
 
 
 
 1  
 
 
 
 inequality constraints with only upper bounds:
 
338922   
  It is decently large, but still a simple quadratic problem with linear constraints. I am solving many of those successfully (and fast) with the MKL PARDISO linear solver used, but this is the biggest one so far.  I am able to solve this in 2 ways:  
  1. Windows, IpOpt 3.7.0, MUMPS linear solver  Number of Iterations....: 82   Total CPU secs in IPOPT (w/o function evaluations)
 
=
 
 521.732  Total CPU secs in NLP function evaluations
 
 
 
 
 
=
 
 
20.381   
  I am normally not using this because it is a lot (sometimes orders of magnitude) slower than the PARDISO version, but this time I ran it for comparison purposes.  
  
  2. Linux, IpOpt 3.12.12, MKL PARDISO linear solver (same laptop as in the above)  The iterations are going the same way as in the previous setup, so I guess it will all be the same in the end .. with the exception that it seems to take forever.  I know it is not apples to apples comparison, but so far I have never seen PARDISO being slower than MUMPS, let alone with such margin. I ran with
pardiso_msglvl and for the first iteration I saw that:  
   === PARDISO: solving a symmetric indefinite system ===  1-based array indexing is turned ON  PARDISO double precision computation is turned ON  METIS algorithm at reorder step is turned ON  Matching is turned ON   
   Parallel Direct Factorization is running on 4 OpenMP  
     
 
 
 
 
 
 
number of equations:
 
 
 
 
 
1096299  
 
 
 
 
 
 
number of non-zeros in A:
 
 
 10792217  
 
 
 
 
 
 
number of non-zeros in A (%): 0.000898  
  
 
 
 
 
 
 
number of right-hand sides:
 
 1  
     
 
 
 
 
 
 
number of columns for each panel: 112  
 
 
 
 
 
 
number of independent subgraphs:
 0     
 
 
 
 
 
 
number of supernodes:
 
 
 
 
 
 
 
 
 
 748178  
 
 
 
 
 
 
size of largest supernode:
 
 
 
 
 
 
 
26102  
 
 
 
 
 
 
number of non-zeros in L:
 
 
 
 
 
 
 
 353891709  
 
 
 
 
 
 
number of non-zeros in U:
 
 
 
 
 
 
 
 1  
 
 
 
 
 
 
number of non-zeros in L+U:
 
 
 
 
 
 
 353891710  === PARDISO is running in In-Core mode, because iparam(60)=0 ===   
   Times:  ======  Time spent in copying matrix to internal data structure (A to LU): 0.000001 s  Time spent in factorization step (numfct)
 
 
 
 
 
 
 
 
 
 
 
 : 430.960081 s  Time spent in allocation of internal data structures (malloc)
 
 : 0.047239 s  Time spent in additional calculations
 
 
 
 
 
 
 
 
 
 
 
 
 
 : 0.000080 s  Total time spent
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
: 431.007401 s   
  So it spent nearly the same amount of time in the first factorization as the MUMPS setup for the whole problem, which definitely makes no sense.
  Subsequent iterations are faster at about 300 seconds each, which is still very bad.  
  I am wondering if I am missing something in the usage of PARDISO in that context, maybe an option that could help or something that seems generally off ? Does anyone have experience with a situation like that ?  
  Thank you very much !  
  Ivo 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20220109/842cc270/attachment.html>