Detect redundant equations

[bchretien]

I just had an issue with the Ipopt plugin and a problem containing some redundant equations:

Exception of type: TOO_FEW_DOF in file "../../../../Ipopt/src/Interfaces/IpIpoptApplication.cpp" at line 887:
 Exception message: status != TOO_FEW_DEGREES_OF_FREEDOM evaluated false: Too few degrees of freedom (rethrown)!

EXIT: Problem has too few degrees of freedom.

Apparently, Ipopt assumes that there is no redundancy:

This somehow assumes that your equations are not redundant, which would be bad in general anyway.

The same thing probably happens in other solvers. Thus, it would be nice to detect this in a precomputation step to ease debugging (redundant constraints would be reported back to the users before letting Ipopt choke on them).

In the meantime, for Ipopt, we can use some undocumented experimental hidden features:

name: dependency_detector  (string)
valid values: none, mumps, wsmp, ma28
default: none
description: Indicates which linear solver should be used to detect 
linearly dependent equality constraints. The default and available 
choices depend on how Ipopt has been compiled. This is experimental and 
does not work well.


name: dependency_detection_with_rhs  (string)
valid values: no, yes
default: no
description: Indicates if the right hand sides of the constraints should 
be considered during dependency detection.
no only look at gradients
yes also consider right hand side


name: mumps_dep_tol (real)
default: 0
description; Pivot threshold for detection of linearly dependent 
constraints in MUMPS.
When MUMPS is used to determine linearly dependent constraints, this is 
determines the threshold for a pivot to be considered zero. This is 
CNTL(3) in MUMPS.

[thomas-moulard]

I had this issue before. However, from the ML these options do not seem to be working well, so unless they are reimplemented somehow on RobOptim side...

[bchretien]

This is what I suggested here. After all, we have early support for postprocessing callbacks, so this could be part of some optional preprocessing callbacks that analyze the problem and assess its properties. In this specific case, that may be a bit complex though... I clearly don't have the time for this, but at least people facing this issue will know how to circumvent it for now.

As for the experimental options, I only tested them with a dummy problem I use for debugging. I would strongly discourage people from using these options in any real-life application.