AMPL vs Java interface

[fueralles]

Hi, I have a problem implemented in AMPL and I like to transfer the model into a Java environment without using AMPL. I used the same options but I do get different results. Even if I use the AMPL solution as a starting point, it is moving out of optimality in my Java code. My implementation in Java seems to be somehow wrong.

I checked the values of the constraints and did the derivative test without any issues. Comparing single constraints in both implementations results in different solutions regarding a non-linear constraint. However, I cannot find the issue. Moreover, at some runs the results of exact vs. approximated Hessian differ.

Therefore, I would like to know, if I can expect the same results and if there are any hints to further test my implementation.

PS: In case it is helpful I can upload the implementation of one of the problematic constraints

[svigerske]

It would be difficult to achieve exactly the same results. Even if you manage to get variables and constraints into the same order as with AMPL, there could still be small numerical differences in function, gradient, etc evaluations due to rounding in floating-pointing arithmetics.

Increasing the print_level for both AMPL and Java versions and looking at the diff may help to see where things start to go different.

[svigerske]

If you get Restoration phase is called at point that is almost feasible..., then this seems to be an old Ipopt version. With current 3.14.0 or 3.14.1, you would see "Cannot call restoration phase at point that is almost feasible", unless, though unlikely, some of the bugfixes prevent this from happening.
This fail comes up if Ipopt is at a point that is feasible, but optimality criteria are not satisfied yet and the routine that tried to find a steplength could not find a steplength that reduces the optimality error along the previously computed search direction. If your Hessian is approximated, then the search direction isn't much accurate and you may want to increase parameter tol.

The installation instructions for coinbrew users already suggest to set --verbosity=3. If that doesn't give enough output, then increase this to 4.

[fueralles]

You are right. That is the error message at older versions. At version 3.14.1 I get
Cannot call restoration phase at point that is almost feasible (violation 2.759792e-12). Abort in line search due to no other fall back. ... EXIT: Error in step computation! Ipopt 3.14.1: Unknown Error

I was used to get optimal results with 'tol=1e-11' at the NEOS server. Trying 'tol=1e-4' has still resulted in 'EXIT: Error in step computation!' at my system. The reason I exclude parameter setting is that I have tested several problems and it is working with the Neos version but not with my compiled one.

I will try to compile it again with '-verbosity=4'.

[fueralles]

I have tested --verbosity=4 for the build process (without hsl now). I haven't found a problem. The warnings for mumps seem to be normal. Maybe someone else is seeing an issue in the build log (build.log)

Furthermore, I have added two IPOPT log files. One with the given exe (ipopt_pre.log) and one with my compiled exe (ipopt_own.log; I have tried it before with the same version but I got similar results).

ipopt_own.log
ipopt_pre.log
build.log

[svigerske]

I don't see anything suspicious in the build log, except that initially you said you use your Java code, but Ipopt's Java interface isn't build because configure doesn't find javac.

I don't know what the "given exe" refers to.

From the ipopt_own.log, I can see that the dual infeasibility is huge and sometimes jumps by several orders of magnitude, but that is all I could see from this log.

[fueralles]

Thanks for taking a look at the files.

I focused on the core modules in the build process. As AMPL does not need the Java interface, I excluded it. In this case, I called AMPL in Java and not IPOPT directly to do the comparison.

The "given exe" is the version that you can find in the software package of AMPL.

I am not sure but I would expect that the formulation causes the dual infeasibility jumps. One variable (the only one I am interested in) can probably lead to a completely different solution space. However, I do not know how to change the formulation. It is in the style of a min-min problem, where "a" is a parameter for the sub-min problem:
min a s.t. min(a) x
Do you have an idea of specific options I could try out?