Optimization, root finding, and nonlinear equation solving

Announcements
1

I’ve been updating my codes to use the Fortran Package Manager, and let me say that this is really a game changer. Where has this been for the past 50 years?! :slight_smile: I’ve got several libraries for optimization, root finding, and nonlinear equation solving, all installable now via FPM.

My Projects

  • roots-fortran – A new package with lots of 1D derivative-free root solvers.
  • nlesolver-fortran – A new package for solving systems of nonlinear equations using basic Newton/Broyden/Linesearch methods for square, overdetermined, and underdetermined systems.
  • fmin – Derivative free 1D function minimizer (classic Brent’s method).
  • simulated-annealing Modernized simann.f for unconstrained optimization.
  • minpack – Modernized MINPACK (NLE solver for square and overdetermized systems).
  • pikaia – Modernized Pikaia genetic algorithm for unconstrained optimization.
  • slsqp – Modernized SLSQP method for constrained nonlinear optimization. One of the optimizers in SciPy.
  • NumDiff – Numerical differentiation using finite differences. Can be used to compute gradients for an optimizer, or for validating hand-coded gradients.

I’ve also got some other FORTRAN 77 abandonware codes that I’ve never used, but am toying with modernizing. Not sure how well they perform yet. See dfo, conmax, and FilterSD

FYI: There are a couple non-free Fortran optimization libraries out there that are quite good:

  • SNOPT (FORTRAN 77) Workhorse library for large-scale nonlinear constrained optimization (SQP). They announced a Fortran 2003 upgrade many years ago, but I don’t believe it is available yet.
  • VF13AD (FORTRAN 77) From HSL Archive. Classic code for dense nonlinear constrained optimization.

Unfortunately, the stagnation of the general Fortran library ecosystem since the 1990s is evident in this field as well. Nobody is really writing cutting-edge optimization libraries in Fortran anymore. Certainly not in modern Fortran. The best we can currently hope for is FORTRAN 77 style interfaces to C++ code (see, for example IPOPT, for large-scale nonlinear constrained optimization, which has a FORTRAN 77 interface that works well.) Sometimes we don’t even get that (e.g., HIOP from LLNL).

24 Likes
2

I am really glad fpm works for you!

I think people either didn’t think they need a package manager, or didn’t know how to do it so that the community adopts it.

What you see here with fpm is an example that it is absolutely possible for a small group of people to lift the whole Fortran ecosystem. Other areas where we still have to deliver is LFortran, stdlib, etc. It is absolutely doable, we just have to do it.

7 Likes
3

Maybe there is interest in these methods:

https://www.ime.usp.br/~egbirgin/tango/codes.php

It is a very mature optimization project for bound-constrainted optimization. (and free - GPL)

5 Likes
4

These look like great candidates for the fpm registry and the packages list

That is an aspect of fpm(1) and fortran-lang.org that needs some attention, IMHO; a command option on fpm(1) (maybethrough a plugin) to add to the fpm(1) registry would be nice. It is a multi-step process currently:
directions.

fpm packages will then show easily in fpm-search as well.

The list is getting long enough this would probably tip the fpm list to starting to need categories, like Beliavsky’s List and/or the Fortran Wiki.

It would be nice if there were one list to add to where you could indicate your package support,
and was as easy to add to as the Fortran Wiki so you can find an entry and see if it is
available via fpm.

3 Likes
5

I think the “packages” list at fortran-lang should be generated by (automatically) merging “packages” and “fpm registry”. And If a package is in both fpm registry and packages, we should remove it from “packages”, as it will get included there by the merge.

For the fpm-registry, I think we urgently need to figure out either namespaces like GitHub (certik/benchmarks and urbanjost/benchmarks) instead of just “benchmarks”, or a good policy to prevent somebody to “reserve” all common words, as happened in Cargo:

4 Likes
6

Ouch. I have seen the problem with DNS names, had not realized it existed with package managers. Not perfect, but perhaps a name would be listed with the fortran-lang.org userID that added it until vetted(?) (another issue); but having so many packages that name clashes are a problem is an issue that would have its upside! Trying to think of something Fortranik like a USE statement can do to demangle but nothing clear is coming to mind. The userID seems like it might be automatable, but not sure; but that is the initial appeal to me. Perhaps name conflicts would be OK but packages would be given a UUID but that seems unwieldy.

2 Likes
7

Great. Thank you. I recently used your JSON-Fortran and Fortran csv module through fpm, and indeed it is a game changer!

5 Likes
8

4 posts were split to a new topic: Modern Fortran interface for NLopt

12

2 posts were split to a new topic: Why is C used in many optimization libraries?

13

A post was split to a new topic: Optimization function similarly to Matlab’s fmincon

14

Update: HIOP does seem to be working on a Fortran interface: C/Fortran interface · Issue #7 · LLNL/hiop · GitHub

1 Like
15

The SciPy root-solvers have a straightforward interface: scipy/scipy/optimize/Zeros at main · scipy/scipy · GitHub. It would be interesting to compare use scipy_zeros with @jacobwilliams’ use root_module.

If anyone is looking for a project to learn about bind(c), this is a good beginner project.