[ADOL-C] memory issue

[Kshitij Kulshreshtha]

As on 2010-09-08 20:29, Rishi Amrit did write:
> On Wed, Sep 8, 2010 at 12:35 PM, Rishi Amrit <amrit at wisc.edu
> <mailto:amrit at wisc.edu>> wrote:
> 
>     Hi,
> 
>        I am using ADOLC to compute sparse jacobian and hessian for
>     solving an optimization problem using IPOPT nlp solver. As required,
>     I first create tapes and generate the sparsity patters using
>     spase_jac and sparse_hess with repeat argument as 0. Then when IPOPT
>     calls the ADOLC function to evaulate the jacobian and hessian at its
>     iterates, I call sparse_jac and sparse_hess with repeat=1, reusing
>     the sparsity pattern computed initialy. Once the optimization is
>     completed, I free up the rind, cind, jacval and hessval variables as
>     required and the function terminates. Now I'm calling this function
>     from octave. When I call the function again with different
>     parameters, the above sequence repeats but what I see is that when
>     sparse drivers are called with ipopt, the memory usage steeps up and
>     hence evaluation time is higher, even though the problem dimensions
>     are the same. I am not sure why this might be happening. Either some
>     memory is not deallocating properly in each call or something. Any
>     ideas on this would be highly appreciated.
> 
> 
> Addendum to my previous email. I compiled ADOLC with debugging enabled
> and ran my code with valgrind. Among the huge chunk of output, here is
> something that caught my attention (See below)
> The number in front of operation 0 seems to keep on shooting high after
> every function call. I am not sure what this number means. 
> 
> Thanks,

In case this is a memory leak the valgrind output should show leak
records. Please send the whole valgrind log.
(use the following valgrind options:
  --log-file=filename.txt
  --tool=memcheck
  --leak-check=full
  --show-reachable=yes
  --track-origins=yes ) <-- this one is not available on some valgrind
versions. If yours does not support this please remove this. Then send
us the filename.txt (or whatever you called it).


As far as the operation counts/taylor counts on the tapes that you noted
are concerned, there is no way we can check or foresee these unless we
have a look at your code which does the taping and evalates gradients
(you must be using the ipopt interface class to feed this to ipopt?)

> 
> ADOL-C warning: !!! Taylor information for tape 3 found that will be
> overwritten !!!
> 

This only means that the taylor buffer from the previous evaluation
somehow survived and will be overwritten. As I said, it is very
difficult to debug this without the code that triggers it.

The counts you see are the number of times a certain operation was
recorded on tape and how many taylors were written due to it.

> 
> Tape contains:
> operation   0:      1 time(s) - 102384 taylors written ( 102384.00 per
> operation)
> operation   1:  10210 time(s) -  20420 taylors written (      2.00 per
> operation)
> operation   2:      1 time(s) -      0 taylors written (      0.00 per
> operation)
> operation   3:   8565 time(s) -  17130 taylors written (      2.00 per
> operation)
> operation   5:   1797 time(s) -   3594 taylors written (      2.00 per
> operation)
> operation   6:   7638 time(s) -  15276 taylors written (      2.00 per
> operation)
> operation  10:      1 time(s) -      2 taylors written (      2.00 per
> operation)
> operation  11:   8690 time(s) -  17380 taylors written (      2.00 per
> operation)
> operation  12:    314 time(s) -    628 taylors written (      2.00 per
> operation)
> operation  13:   2700 time(s) -   5400 taylors written (      2.00 per
> operation)
> operation  15:   5695 time(s) -  11390 taylors written (      2.00 per
> operation)
> operation  16:  11533 time(s) -  23066 taylors written (      2.00 per
> operation)
> operation  32:      1 time(s) -      0 taylors written (      0.00 per
> operation)
> operation  33:      1 time(s) -      0 taylors written (      0.00 per
> operation)
> operation  34:      1 time(s) -      0 taylors written (      0.00 per
> operation)
> operation  35:      2 time(s) -      0 taylors written (      0.00 per
> operation)
> operation  39:      1 time(s) -      0 taylors written (      0.00 per
> operation)
> operation  41:   2999 time(s) -   5998 taylors written (      2.00 per
> operation)
> operation  44:   6004 time(s) -  12008 taylors written (      2.00 per
> operation)
> operation  45:   1351 time(s) -   2702 taylors written (      2.00 per
> operation)
> operation  54:   4959 time(s) -      0 taylors written (      0.00 per
> operation)
> 
> 

-- 
Kshitij Kulshreshtha

Institut für Mathematik,
Universität Paderborn,
Warburger Straße 100,
33098 Paderborn.

Büro: A3.235

Privatanschrift:
Arnikaweg 62
33100 Paderborn.