[Coin-ipopt] IPOPT unpredictably ignores AMPL variable inits

[Andreas Waechter]

Hi Frank,

Thanks for the detailed message - the behavior you describe is indeed
weird.  Did you observe this on any other executable than that generated
in Cygwin?  (E.g. some Unix or so?  - The NEOS Ipopt solver runs on Linux,
by the way).

When you write "random" values: Are those really random, i.e. are the
entries of the initial X in IPOPT.OUT different everytime you observe this
funny behavior?  Also, do you see very large/small number (1e-310 or so)
in there, or are they of reasonable size?

Since you mentioned the opimization level:  Does everything work if you
compile with -O2 or -g ?

Also, I ran the code again with valgrind (memory checker on Linux, which
so far I found very useful), which would complain if uninitialized memory
is accessed, but the run was clean (well, there always shows something up
in the ASL in the first Hessian evaluation, but that happenes later after
the initial value is already computed).  It seems to me that the Linux
version is clean, but maybe some #define's are different for Cygwin...?
(I don't know the ASL code, and I usually don't use Windows...)

Does anyone else reading this message have an idea what is going on, or
observed similar unpredictable behavior (on Cygwin or otherwise)...?

Thanks

Andreas


On Fri, 20 May 2005, Frank J. Iannarilli wrote:

> Hi,
>
>
> Evidently, IPOPT occasionally, unpredictably IGNORES the variable
> initializations I impose within my problem submission from AMPL (the .dat
> file), and randomly initializes the starting point.
>
>
> I'm trying to reproduce a case on my local IPOPT installation, that I first
> ran on the NEOS server.
>
>
> =========  CASE RUN ON NEOS  ==========
>
> I run a case on NEOS with IPOPT's scaling defaults, and get screen output:
>
>  get_scale: |g|_inf =   1.
>  get_scale: QFSCALE =   1.
>  get_scale: smallest CSCALE =   1.
> get_scale: No scaling of constraints necessary
>
> Note the "smallest CSCALE" value - it figures in what follows.
>
> Recall that the constraints scaling is done based on the gradient evaluted
> at the initial values of the variables, which can be set (initialized) from
> AMPL.  I initialize a subset of my variables.
>
>
> ================================================================
> =====  CASE RUN LOCALLY - AMPL/IPOPT NOT Initializing???  ======
>
> Now I try to reproduce my case on my own local machine, with AMPL and my
> own   compiled copy of IPOPT (version 2.2.1d; same as IPOPT at NEOS).  I'm
> on Win2KPro, having compiled with Win32-native MinGW/MSYS.  With options
> IFILE=1 and IPRINT=10, an IPOPT run produces output file IPOPT.OUT
> (IPRINT=10 produces TONS of output - be careful out there!).
>
> I attempt the case run *several times*, and get the screen output showing:
>
>    get_scale: smallest CSCALE =   0.113303
>
> which is DIFFERENT from my baseline NEOS run!
>
> I check the IPOPT.OUT file, and see that IPOPT is NOT using my
> initialization values for the variables I thought I had initialized (within
> my AMPL .dat file) - they're random (albeit within-constraints).
>
>
> ================================================================
> =====  IT GETS WEIRD - AMPL/IPOPT TRIPS TO CORRECT INIT  ======
>
>
> Now here's where it gets weird:
>
> Within AMPL, I force the ".nl" interface file (handed-off from AMPL to
> IPOPT) to be written in "generic ascii" form (default is binary) -- I want
> to eyeball-inspect the variable initialization values going from AMPL to
> IPOPT.  {within ampl: option solver ipopt; option ipopt_oopt g}.  The .nl
> file shows correct initialization values.
>
> Then I invoke ampl: solve.  Remarkably, IPOPT's screen output is *now*
> indicating I'm reproducing my NEOS case:
>
>      get_scale: smallest CSCALE =   1.
>
> and inspecting the IPOPT.OUT file NOW indicates the correct variable
> initializations as well!!
>
> ++++++++
>
> To see whether this behavior is due to use of ascii .nl files (it's
> evidently not -- see below), I start a new ampl session, verify by
> interdiction that AMPL is writing a binary .nl file, and rerun my case.
> Incredibly, instead of the screen output showing:
>
>    get_scale: smallest CSCALE =   0.113303
>
> as before, it's STILL showing:
>
>      get_scale: smallest CSCALE =   1.
>
> And I can restart new session after session, and things are now behaved!  I
> verified that even in binary-.nl AMPL file mode, the IPOPT.OUT file is NOW
> showing proper variable initialization!!
>
> BTW, I now reproduce my case virtually exactly compared with NEOS run.
>
>
> ================================================================
> =====  BUT IT'S UNPREDICTABLE!!  ======
>
> But occasionally, I can rerun, and get:
>
>    get_scale: smallest CSCALE =   0.113303
>
> **When this happens**, IPOPT.OUT reveals that, once again, the variable
> initializations are random, in defiance of AMPL's inits!!
>
>
> ================================================================
> =====  OSTENSIBLE HYPOTHESES AND COUNTER-ARGUMENTS  ======
>
>
> 1. Something's screwed up with my compilation of ASL (AMPL Solver Library)
> hookup to IPOPT?  -O2 instead of -O3??
>
>
> 2.  Maybe ASL's (in fg_read.c/fgh_read.c/pfg_read.c) assuming that NULL
> pointer = 0 (or !(active-pointer) = 1) unpredictably faulty?
>
>    			case 'x':
> 				if (!xscanf(R,"%d",&k)
> 				|| k < 0 || k > nv0)
> 					badline(R);
> 				if (!X0 && want_xpi0 & 1) {
> 					x = nv0*sizeof(real);
> 					if (want_xpi0 & 4)
> 						x += nv0;
> 					X0 = (real *)M1zapalloc(x);
> 					if (want_xpi0 & 4)
> 						havex0 = (char*)(X0 + nv0);
> 					}
> 				while(k--) {
> 					if (xscanf(R, "%d %lf", &j, &t) != 2)
> 						badline(R);
> 					if (X0) {
> 						X0[j] = t;
> 						if (havex0)
> 							havex0[j] = 1;
> 						}
> 					}
> 				break;
>
>
> X0 is malloc'ed outside of fg_read(), as encouraged in AMPL Solver Hookup
> manual (and IPOPT code), thus it appears the logic above precludes havex0
> from ever being malloc'ed -- although it appears IPOPT doesn't look at
> these values (i.e., takes X0 as-is, not caring if init by user, or zeroed
> by ampl).
>
> IDEAS I can try?
>
>
> Thanks!
>
>
>
> Frank J. Iannarilli, franki at aerodyne.com
> Aerodyne Research, Inc., 45 Manning Rd., Billerica, MA 01821 USA
> www.aerodyne.com/cosr/cosr.html
> _______________________________________________
> Coin-ipopt mailing list
> Coin-ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-ipopt
>