Ipopt doesn’t tell us where the issue is. It just says it found an issue.
I assume GAMS does what JuMP would like to do, which is for us to evaluate the various callbacks and look for NaN or Inf. This requires a bit of effort though. It’s non-trivial at the moment.
Three of the points in Tools to test and debug JuMP models · Issue #3664 · jump-dev/JuMP.jl · GitHub are relevant:
Bounds given as constraints
Identify constraints of the form @constraint(model, l <= x <= u). These should instead be specified as @variable(model, l <= x <= u).
Motivation: The former adds a new linear constraint row to the problem. The latter sets a variable’s bounds. Solvers typically have specialised support for variable bounds. If the solver doesn’t have specialised support for variable bounds, JuMP will reformulate into the constraint version.
Prior art: Most solvers have a presolve that does this, but it’s a sign of user-error that could be improved.
Starting point analysis
Starting points which violate domain restrictions like log(x) when x = 0 to start are common. Therefore, we should analyse the feasibility of a given starting point, and potentially that of the first- and second-derivatives as well.
Domain analysis
Nonlinear programs often include terms like log(x) where x >= 0. This is a common cause of domain violations because the solver may try x = 0. It’s usually better to add an explicit lower bound on x of x >= 0.01.