[Coin-ipopt] IPOPT unpredictably ignores AMPL variable inits

[Frank J. Iannarilli]

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