Issue with calling Knitro

I use pyomo to formulate my problem and then use ampl to call knitro to solve my problem, as show in code below.
self.solver_pyo = pyo.SolverFactory(modules.find(“Knitro”), solve_io = “nl”)

And my program contains 3 processes to solve three different problem simultaneously, with two successfully returns local optimal solution, the third one reports error with message below:
ERROR: Solver (asl) returned non-zero return code (-11)
ERROR: See the solver log above for diagnostic information.

I have checked the document of Knitro, it didn’t explain return code (-11).

So I wonder if anyone could explain it why it didn’t work, or should I post this issue on somewhere else ?

Appreciate your answer !

Since you are calling Knitro from Pyomo (rather than AMPL), and the error occurred while the Knitro solver was running, I suggest that you post this to Knitro support. You can send an email to or post to

We see that Richard Waltz replied for Knitro as follows:

I am not familiar with these error messages. The error messages you report do not come from Knitro itself. Rather they likely come from the Ampl Solver Library (asl) or from Pyomo. I would suggest contacting the AMPL or Pyomo teams to see if they have some information here. Note that the Pyomo interface is not maintained by Artelys.

There are also return codes that the AMPL-solver library (ASL) returns from a Knitro run, but they do not include -11 (or 11).

Another possibility is that Pyomo is returning some other error code — defined by the operating system or by Pyomo itself — which is unrelated to either AMPL or Knitro. To investigate, you can post your question to the Pyomo Forum.

If that doesn’t help, then see if you can capture the .nl file that Pyomo writes and sends to Knitro’s ASL interface. We do not maintain Pyomo, but we do maintain ASL; so if you could send us that file, we could feed it to Knitro’s ASL interface on our computers, to get more information about where the Pyomo-Knitro run is terminating.

Appreciate your reply.
Do you mean that I should store the .nl file before calling solve function ? Then I suppose the optimization problem itself would not be the issue, because I have solve the same problem a few iterations before, all I changed just a few parameters. I wonder if there any possibility that the solver might be running out of memory ? Of course I could sent you the .nl file later on when I encounter the same issue again.
Also, I will try to post this issue to the Pyomo Forum to figure out whether Pyomo accounts for this issue.
Thanks again for your patient answer.

According to a StackOverflow post (How to get nl file from pyomo from inside pyomo script solver?), you can store the .nl file either before solving, or as part of the solve function’s execution.

We can use the .nl file to solve your optimization problem using the ASL version of Knitro (which is what Pyomo uses). By doing that, we can hope to determine whether the error occurs in the ASL interface or in the Knitro algorithm. That will be a valuable step in determining what caused the error.

Note that on Linux systems, a return code of -11 indicates a crash due to a SIGSEGV error, which is well documented on the internet. This might occur when a process runs out of memory, but the statistics in Knitro’s output suggest that your problem probably isn’t large enough to have memory issues.

the output shows a single problem’s size, I have three same size problems running parallel and my memory is 16G.

Even with 3 of your problems running in parallel at the same time, if they are of that same size then I would not normally expect a need for more than 16 Gbytes of memory. But as a start on determining the actual cause of the error, you could try a few tests:

  • If you run the problems one at a time (not in parallel) then do you still get an error?
  • If you run the 3 problems in parallel, but you change the order in which the Knitro processes are spawned, is it always the same problem that terminates with the error?

Also, if any of Knitro’s parallel options are being used, there might be a conflict between the 3 Knitro processes, especially if all 3 processes are trying to use as many threads as possible. You can check this by testing whether an error still occurs when you set Knitro’s numthreads option to 1.