[Couenne] MUMPS memory errors when running Couenne in GAMS

[Tony Kelman]

Stefan,

Thanks for your help. I was making a dumb mistake on the options files
when running locally, I wasn't putting them in the default GAMS project
directory so it was indeed ignoring my changes to mumps_mem_percent. I'm
continuing to do more tests locally but it takes several hours to run each
instance. The NEOS server was much faster but the GAMS run via the BARON
page didn't seem to recognize Couenne options files, whether I called it
couenne.opt or baron.opt on upload. I wasn't seeing the "List of user-set
options:" display in those runs.

GAMS/CONVERT is mighty useful, thanks for that tip! Looks like the NEOS
server's installation of Ipopt via AMPL is using Ma27, but via GAMS is
using MUMPS. The memory error when I run Couenne is also happening when I
use Couenne via AMPL on NEOS - my last page of node status messages is
interspersed with these errors (in this order, one of each, but with
several iteration messages between them):

Error: terminate called after throwing an instance of 'std::bad_alloc'
Error:   what():  St9bad_alloc
Error: error running couenne:
Error: 	termination code 6
<BREAK>

I guess I'll try increasing ma27_la_init_factor, ma27_liw_init_factor,
and/or ma27 _meminc_factor, unless anyone's got any better ideas.

I was able to get the source for Ma57, but I'm running Windows here so I
didn't get very far compiling it. I tried make in cygwin using gcc-g77,
but got a few "linker input file unused because linking not done",
"Invalid token at (2) in expression or subexpression at (1)", and
"Reference to unimplemented intrinsic 'EPSILON'/'TINY'/'HUGE'/'RADIX' at
(^) (assumed EXTERNAL)". I think I saw two versions of Ma57, one called
HSL_Ma57 - I'll try whichever one I didn't download yet, see if that
behaves any differently.

Still quite confused why these runs are taking about 10x as long to get to
the same number of iterations when I do them locally vs on the NEOS
server. The server was only about 1.5x faster than my machine when I was
trying BARON on the same model. Maybe it's a number of cores /
parallelization thing?

Anyway, would appreciate any advice on this memory hangup from you or others.

Thanks,
Tony