[Ipopt] Size of double precision work space too small

[Andreas Waechter]

Hi Xiaoming,

The Fortran version of Ipopt is no longer maintained.  I suggest you 
switch to the newer C++ version, which also has a Fortran interface if you 
prefer that.  With that, memory management is completely different and 
transparent to the user.

Regards,

Andreas

On Mon, 14 Apr 2008, Xiaoming Yu wrote:

> Hi Dr. Wachter :
>
> 1) I am using IPOPT version 2.2.1e (FORTRAN).
>
> estimated double precision work space requirement =       617084
> estimated integer work space requirement          =      1168269
>
> I gave
>      LIW  =     50000000
>      LRW =     100000000
>
> As you can see LIW >> LIWe and LRW >>LRWe. However, I still have
>
>
> An error occoured after            0  Iterations.
> The error code is           98
>
> EXIT: Size of double precision work space too small
>
> I defined :
>
>      NARGS = 6
>      ARGS(1) = 1.d-3
>      CARGS(1) = 'dtol'
>      ARGS(2) = 10
>      CARGS(2) = 'iprint'
>      ARGS(3) = 1
>      CARGS(3) = 'ifile'
>      ARGS(4) = 6
>      CARGS(4) = 'IQUASI'
>      ARGS(5) = 50
>      CARGS(5) = 'IMAXITER'
>      ARGS(6) = 1.1D0
>      CARGS(6) = 'DFILLINFACT'
>
> The problem size is ( 153 design variables with lower and upper bounds,
> and 469 inequality constraints) :
> Number of variables           :      622
>   of which are fixed         :        0
> Number of constraints         :      469
> Number of lower bounds        :      153
> Number of upper bounds        :      622
> init_mem: After CONSTR LRS_END =       583436 LIS_END =       583436
> Number of nonzeros in Jacobian:   291718 (full dense)
> init_mem: After MAINLOOP LRS_END =       609161 LIS_END =       583436
> init_mem: After FILTER LRS_END =       617194 LIS_END =       583436
> init_mem: After RESTO_FILTER LRS_END =       647739 LIS_END =
> 583436
> init_mem: After RESTO_TRON LRS_END =       647739 LIS_END =
> 583436
> init_mem: After GET_STEP_FULL LRS_END =       647739 LIS_END =
> 1172327
> init_mem: After OPTERROR LRS_END =       647739 LIS_END =      1172327
> init_mem: After GET_HV =       647739 LIS_END =      1172327
> |grad F|_max = 0.11D+02
> get_scale: |g|_inf =    10.7422475814819
> get_scale: QFSCALE =    1.00000000000000
> get_scale: smallest CSCALE =   0.243789316867635
>
> My question is : (1) Why is the estimated space too small? (2) MAT27 (or
> linear system solver) is the key for the memory requirement? (3) The C++
> version IPOPT requires less memory than the FORTRAN version?
>
> Thanks,
>
> Xiaoming
>
>
>
>
> -----Original Message-----
> From: ipopt-bounces at list.coin-or.org
> [mailto:ipopt-bounces at list.coin-or.org] On Behalf Of Sebastian Nowozin
> Sent: Sunday, April 13, 2008 4:42 AM
> To: Stefan Vigerske
> Cc: ipopt at list.coin-or.org
> Subject: Re: [Ipopt] Best and free way of interacting with IPOPT on
> Linux
>
> On Sun, Apr 13, 2008 at 12:42 PM, Stefan Vigerske <stefan at vigerske.de>
> wrote:
>
>>  As far as I know, there are several interfaces available:
>>  - C, C++, Fortran
>>  - Java
>>  - Matlab
>>  - AMPL, GAMS
>
>> [...]
>>  Also the Java and Matlab interfaces I have never tried, but they also
>>  require you to implement derivative evaluation methods. It might also
> be
>>  that the communication between the Java or Matlab world on the one
> side
>>  and the C++ world on the Ipopt side has an impact on the efficiency.
>>  With the AMPL and GAMS interfaces specification of the model is more
>>  convenient, but they might not fit into the "free" category. Even
> though
>>  the interfaces are for free, the compiler for the algebraic model to
> an
>>  instance that the interface can understand is not free for larger
>>  models. Note that Ipopt is also included the GAMS distribution.
>
> The Matlab interface is great and works like a charm (thanks to
> Peter), I have used it often in the last few months.  However, usually
> it is not the most efficient because all the different computations
> are split up across functions (computeObjective, computeGradient,
> computeJacobian, computeHessian).  For most problems I have worked
> with you could do this calculation more efficiently if you could
> calculate them together.  As Matlab's function interface is strictly
> functional (i.e. no side effects), this is not possible with the
> current interface, except by using hacks such as global variables and
> checking if recomputation is necessary.
>
> Sebastian
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>