@cvanaret I would appreciate your review again. Theres a skipped test of problem 109 (TP109) from the Schittkowski test that I wasn't able to get to converge with Uno.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.99%. Comparing base (92cd835) to head (f75e2de).

@@           Coverage Diff           @@
##             main     #483   +/-   ##
=======================================
  Coverage   82.99%   82.99%           
=======================================
  Files           1        1           
  Lines         147      147           
=======================================
  Hits          122      122           
  Misses         25       25           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@robfalck thanks for the PR!

I have an AMPL model of hs109 and Uno indeed doesn't converge with hessian_model="LBFGS" + the default quasi_newton_memory_size=6. It looks like the Hessian approximation is too positive definite and the solver takes tiny steps.
It does converge for quasi_newton_memory_size=15 but that's just lucky.

I think I should monitor progress and flush the limited memory if the solver stalls. Note that I'm also planning to implement interior points with L-BFGS in the next few days.

Will the exact Hessian callback be available in the near future?

Thanks for checking. That last question is up to the mdolab folks since it's a significant change.

unopy v0.4.1 is out with:

• L-BFGS for interior-point methods:

uno_solver.set_preset("ipopt")
# either set the Hessian model explicitly
uno_solver.set_option("hessian_model", "LBFGS")
# or let Uno default to L-BFGS if no Hessian is provided

• a function set_logger_stream:

uno_solver.set_logger_stream(sys.stdout)
uno_solver.optimize(model)
sys.stdout.flush()

# or

with open("log.txt", "w") as f:
    uno_solver.set_logger_stream(f)
    uno_solver.optimize(model)
    f.flush()

Will the exact Hessian callback be available in the near future?

It would be a very cool capability to add since most gradient-based optimizers should support that, but I don't believe that the lab (pinging @A-CGray @eirikurj ) is interested in adding this capability in the near term. Most of the (high-fidelity) codes used for engineering MDAO do not provide second derivatives.

I haven't thought this through yet but I think it would require a change in API of the _masterFunc and _masterFunc2 callback function wrappers and some non-naive way to store sparsity information, so it would not be a trivial implementation. I also know that @ewu63 has been considering some major code refactoring at some point, so this change could fall under that bigger effort.

Will the exact Hessian callback be available in the near future?

It would be a very cool capability to add since most gradient-based optimizers should support that, but I don't believe that the lab (pinging @A-CGray @eirikurj ) is interested in adding this capability in the near term. Most of the (high-fidelity) codes used for engineering MDAO do not provide second derivatives.

I wouldn't complain if somebody else implemented it, but we have no plans to. We are rarely (if ever) solving problems where the Hessian is computable in any practical sense. If somebody was going to implement this, we may as well implement the ability to use jacobian-vector products as well.

Thanks for doing this work @robfalck , I have been meaning to try out Uno for a long time, now I might actually get around to it!

Hi all, I am working through some testing environment issues on my side and I am currently running stuff on docker to prepare the other PR. Anyway, I kept bumping into this weird error that makes all the Uno tests fail when running testflo:

TypeError: protected_actual_reduction_macheps_coefficient is not of type int triggered on this line

Even if I make sure that the option defined in this line is actually an int, the error persists. Only if I remove the option altogether the tests actually converge. @robfalck do you have any issues like that on your side?

Hi @marcomangano, can you try 10. instead of 10?
The option should be a float but it looks like the wrong unopy overload is called.

Hi @marcomangano, can you try 10. instead of 10? The option should be a float but it looks like the wrong unopy overload is called.

Ha, that fixes it, good catch! I am not very fluent in cpp, is it because 10 is read as an int by the cpp layer here? Anyway, pushing the quick fix here for now. I cannot commit directly to Rob's branch, but that is an easy fix for later.

Ha, that fixes it, good catch! I am not very fluent in cpp, is it because 10 is read as an int by the cpp layer here?

Great!
Yes, it picks the right function given the type of the argument, so with 10 it will naturally pick the integer one. A bit stringent, but this avoids implicit conversions between types.

Don't have access to a computer but hopefully my update today via GitHub mobile fixed it.

unopy v0.4.2 is out. The ipopt preset with L-BFGS Hessian should be able to solve hs109.