[Ipopt] A large optimization problem

[Krish Krishnan]

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



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/ipopt/attachments/20080801/aba017b1/attachment.html