Convention for rim data? about qpsreader.jl HOT 3 CLOSED

entries in subsequent sections that correspond to unregistered rows should be ignored, not raise an error

Currently, this case is not explicitly handled, however, a KeyError will be raised, e.g., here, when a row is encountered whose name has not been seen before.

from qpsreader.jl.

I don't have very strong feelings here but I'm in favor of an implementation that does not silently ignore data.

If we don't currently accept multiple objectives, I'm in favor of throwing an error when multiple objectives are defined, and possibly allowing an option (defaulting to false) that, when set to true, would cause subsequent objectives to be ignored.

Another possibility is to use logging to warn the user that objective rows (or right-hand sides) were ignored.

Summing duplicate coefficients seems reasonable. Again, a warning could be issued if we find any.

Duplicate entries in RHS, BOUNDS, RANGES sections over-write previous entries.

Again I would prefer to raise an error and ask to user to explicitly set an option if they know what they're doing.

It would be good to have a list of MPS files that we currently can't handle and the reason why we can't handle them. We could tick off boxes as we make progress.

from qpsreader.jl.

Another possibility is to use logging to warn the user that objective rows (or right-hand sides) were ignored.

I would prefer that option over throwing an error if multiple objectives/RHS/bounds/etc. are encountered.

For instance, Mosek displays which objective/RHS/bounds/etc... was selected, with the convention that others are ignored:

Open file 'mps/stat96v1.mps.gz'
Reading started.
Using 'OBJ.FUNC' as objective vector
Read 972414 number of A nonzeros in 0.25 seconds.
Using 'RHS' as rhs vector
Using 'BOUNDS' as bound vector
Reading terminated. Time: 0.25

(from this logfile in Hans Mittelmann's benchmark).

from qpsreader.jl.