You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, PyNumero's ASL interface handles evaluation errors by asserting the return value of the interface's eval_g function here. To handle this error, e.g. in a solver interface, one would have to catch the error, something like:
try:
nlp.evaluate_constraints()
exceptAssertionError:
# Follow whatever convention the solver uses for eval errorsreturnFalse
This is dangerous as it catches any assertion error (e.g. the check for consistent dimensions). I propose we have something like a PyNumeroEvaluationError that we raise in this case that can safely be caught and handled by solver interfaces.
Presumably, we could also provide some information about which constraint caused the evaluation error, which would be useful for debugging. Ipopt's AMPL interface does this, although from a quick glance at the ASL evaluation functions it was not obvious to me how this is done.
Rationale
This is one step towards a CyIpopt interface that handles function evaluation errors in the same way that Ipopt (AMPL interface) does. The other steps are to handle evaluation errors in CyIpopt and to integrate both of these in our CyIpopt interface.
The text was updated successfully, but these errors were encountered:
Presumably, we could also provide some information about which constraint caused the evaluation error, which would be useful for debugging. Ipopt's AMPL interface does this, although from a quick glance at the ASL evaluation functions it was not obvious to me how this is done.
It looks like the additional information that Ipopt displays with halt_on_ampl_error yes comes from ASL, and I can't figure out exactly where it comes from. At the high-level ASL interface, we have the following options:
Ignore an evaluation error but set the error flag (this is what we currently use in PyNumero)
Halt on error and print a message. I don't think this is useful for us. We want the program to keep executing.
One option to provide useful information on errors in Jacobian/constraint evaluation would be to call conival and jacival for each constraint and make a note of which set the error flag. This information could then be passed up to Python where we can print useful debugging information.
Summary
Currently, PyNumero's ASL interface handles evaluation errors by asserting the return value of the interface's
eval_g
function here. To handle this error, e.g. in a solver interface, one would have to catch the error, something like:This is dangerous as it catches any assertion error (e.g. the check for consistent dimensions). I propose we have something like a
PyNumeroEvaluationError
that we raise in this case that can safely be caught and handled by solver interfaces.Presumably, we could also provide some information about which constraint caused the evaluation error, which would be useful for debugging. Ipopt's AMPL interface does this, although from a quick glance at the ASL evaluation functions it was not obvious to me how this is done.
Rationale
This is one step towards a CyIpopt interface that handles function evaluation errors in the same way that Ipopt (AMPL interface) does. The other steps are to handle evaluation errors in CyIpopt and to integrate both of these in our CyIpopt interface.
The text was updated successfully, but these errors were encountered: