[Ipopt] A large optimization problem

[Damien Hocking]

Guys,

There was some stuff on the MUMPS list about this kind of thing a few weeks ago.  It's supposed to be fixed in MUMPS 4.8.0 which was released last week.  I haven't had the chance to run 4.8.0 in IPOPT yet but I'll try this weekend.

Damien 
  _____  

From: Andreas Waechter [mailto:andreasw at watson.ibm.com]
To: Krish Krishnan [mailto:rkrishnan8216 at yahoo.com]
Cc: ipopt at list.coin-or.org
Sent: Fri, 01 Aug 2008 09:05:13 -0600
Subject: Re: [Ipopt] A large optimization problem

Hi Krish,
  
  Did you run your code through a memory checker?  Is this first element 
  in IRN being set in your code?
  
  We have been using MUMPS for a few years now, and it seems to run very 
  robustly.  However, Stefan in his posting seems to indicate that MUMPS 
  crashes (but I doubt that this is a hard crash like a seg fault, or rather 
  some problem like exceeding memory).  You could of course try to see what 
  happens when you use MA27 as an experiment.
  
  But I would carefully check if you are setting the values correctly in 
  your method that are called by Ipopt to get the sparsity pattern.  Maybe 
  for some reason you skip the first entry.  It might really be helpful to 
  run your code with a derivative checker (like valgrind on windows) on a 
  preferrably small instance of your problem (otherwise you have to wait 
  forever) - if you do that, I would set the Ipopt print_level very high, so 
  that it will print out the values of the Jacobian and Hessian as well, and 
  if there is something uninitialized, valgrind would complain about before 
  the problem is detected in MUMPS.
  
  Regards,
  
  Andreas
  
  
  On Fri, 1 Aug 2008, Krish Krishnan wrote:
  
  > Hi all:
  >
  > I have a rather large portfolio optimization problem.  I am trying to use IpOpt with Mumps (due to licensing issues).
  > I first outline the steps to create the problem.
  >
  > I derive a class COpt from IpOpt.
  > An instance of COpt is p_optdata
  >
  > I next create the two smart pointers as follows:
  > SmartPtr<COpt> p_optdata;
  > SmartPtr<TNLP> p_optdata_tnlp;
  >
  > p_optdata = new COpt();
  > p_optdata_tnlp = GetRawPtr(p_optdata);
  >
  > I set up the problem as follows:
  >
  > void CBMOptDoc::optimize()
  > {
  >    // Create an instance of the IpoptApplication
  >    SmartPtr<IpoptApplication> app = new IpoptApplication(false, false);
  >    // Initialize the IpoptApplication and process the options
  >    ApplicationReturnStatus status;
  >    status = app->Initialize();
  >    if (status != Solve_Succeeded)
  >    {
  >        AfxMessageBox("Error during initialization");
  >        return;
  >    }
  >    status = app->OptimizeTNLP(p_optdata_tnlp);
  >
  >    if (status == Solve_Succeeded)
  >    {
  >        Index iter_count = app->Statistics()->IterationCount();
  >        Number final_obj = app->Statistics()->FinalObjective();
  >    }
  > }
  >
  >
  >
  >
  >
  > bool COpt::get_nlp_info(Index& n, Index& m, Index& nnz_jac_g,
  >                        Index& nnz_h_lag, IndexStyleEnum& index_style)
  > {
  >    int nassets = ml.m_nAssets;
  >    int kvars = nRI + nInd;
  >    n = 2 * nassets;
  >
  >    m = 4 + kvars;
  >
  >    // nonzeros in the jacobian,
  >    nnz_jac_g = (7 + 2 * kvars) * nassets ;
  >
  >    // and nonzeros in the hessian of the lagrangian
  >    nnz_h_lag = (2 * nassets + 1) * (nassets + 1);
  >
  >    // We use the C index style for row/col entries
  >    index_style = C_STYLE;
  >
  >    return true;
  > }
  >
  >
  >
  > Here nassets = 501, kvars = 22 so the number of non-zeros are fairly 
  > large.  I provide the needed jacobians and hessians.
  >
  > When I get into app->OptimizeTNLP(p_optdata_tnlp), the application gets 
  > as far as line 1022 of dmumps-part7.f and crashes.  The reason is that 
  > the arrays IRN and ICN in the module are corrupted .  A partial look at 
  > IRN shows that IRN(1) has garbage in it.
  >
  > -        IRN    {...}    INTEGER(4)
  >        IRN(1)    -842150450    INTEGER(4)
  >        IRN(2)    1    INTEGER(4)
  >        IRN(3)    2    INTEGER(4)
  >        IRN(4)    2    INTEGER(4)
  >        IRN(5)    3    INTEGER(4)
  >        IRN(6)    3    INTEGER(4)
  >
  > Similarly ICN is also corrupted at ICN(1).
  >
  > Any thoughts on where I could be going wrong?  Appreciate your help as I have put in a lot of effort over the last two months on this.I wouldn't have gotten this far without your feedback. If needed I can provide the jacobian and hessians.
  >
  > Thanks a lot.
  >
  > Krish
  >
  >
  >
  >
  _______________________________________________
  Ipopt mailing list
  Ipopt at list.coin-or.org
  http://list.coin-or.org/mailman/listinfo/ipopt
    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/ipopt/attachments/20080801/aa260c63/attachment.html