[Coin-discuss] comments, MPS I/O routines

[Lou Hafer]

Folks,

	Dylp doesn't have a native MPS write routine, and unitTest now
requires it, so I decided to build one from CoinMpsIO (CMI) pieces while
repairing OsiDylpSolverInterface (ODSI).  Overall, it was pleasantly easy --
basically a call to CMI::setMpsData, then a call to CMI::writeMps. But I have
a bunch of lingering questions, and some comments.  Some of them spring from
reading MPS using dylp's native readMps routine and writing with CMI code.
(That's also how I ended up tweaking the bugs in CoinMpsIO.)

	There's an odd asymmetry at the OsiSolverInterface (OSI) level. For
reading, there's a single function,
  virtual int OSI::readMps (const char *filename,
			    const char *extension = "mps") const = 0

For writing, there are two, 
  virtual void OSI::writeMps (const char *filename,
			      const char *extension = "mps") const = 0
and
  int OSI::writeMps(const char *filename,
		    const char ** rowNames, const char ** columnNames,
		    int formatType=0,int numberAcross=2) const ;

Is this asymmetry intentional? The second (non-virtual) writeMps can't be
easily overridden. What really got me to wondering was the test sequence in
OSI::OsiSolverInterfaceCommonUnitTest:

  si1->readMps(fn.c_str(),"mps");
  si1->writeMps("test.out",NULL,NULL);
  si1->writeMps("test2","out");
  si2->readMps("test.out","");

This will do all its reading using a <solver-specific>::readMps routine, but
will write test.out with OSI::writeMps. I assume the idea is to read with the
solver-specific routine, write with a known (COIN-supplied) routine, then
read with the solver-specific routine. But it doesn't really test the
solver-specific writeMps routine (other than making sure it can write
test2.out without a fatal error). Writing a test to write with the
solver-specific routine and read with a COIN-supplied read routine strikes me
as a more difficult proposition, unless we adopt clp as the standard solver
and use it in the test sequences. Clearly just comparing MPS files is
futile.

	What's the plan for compressed format read/write support? Right now,
there's no program level control --- the only way to turn it on or off is at
compile time. Are we moving to require this of all solver interfaces? Should
it be under programmatic control? Perhaps an option in a CMI object?

	Various other random questions/observations:

  * Seems like there should be a CMI::setProblemName routine.

  * Is formatType intended to be used as a bit vector, or are the various
    options mutually exclusive?  I've looked over usage in the code and am
    still uncertain.

							Lou