Modern Fortran interface to ODEPACK

I made a modern Fortran interface to the LSODA routine in ODEPACK: GitHub - Nicholaswogan/odepack . ODEPACK solves ordinary differential equation initial value problems. LSODA can deal with stiff and non-stiff problems by automatically switching between appropriate methods.

This repository modifies the original ODEPACK source code. The main difference is that I have replaced common blocks with a passed derived type. This makes the code thread safe

Features include

  • easy to use object-oriented interface
  • root-finding
  • thread safe
  • Jacobian can be dense or banded

I am considering replacing the linear algebra matrix routines, which are LINPACK, with calls to more highly optimized LAPACK routines. I’m guessing this would matter for big problems. Any thoughts on the value of this are appreciated.

Any other feedback/issue is also welcome.


3 posts were split to a new topic: Conditionally linking LAPACK with fpm

Thanks a lot for this updated interface, @nicholaswogan. I am big fan of odepack and it’s really nice that we can now employ this set of ODE solvers in a modularized and object-oriented way.
I noticed that you “only” (please don’t take this negatively) made interfaces to LSODA and LSODAR. Are you planning to extend the work to other solvers, e.g. LSODE? For problems that I know for sure are stiff, I prefer calling LSODE with the correct method flag, rather than letting LSODA discover that on its own.
Thanks again for this contribution. Really cool.

1 Like

No problem! I might put the same effort into LSODE, but not in the near future. I need routines which have root finding, and unfortunately, LSODE doesn’t have root finding.

1 Like

Are you willing to accept pull requests with the minimum refactorings needed to get rid of the -std=legacy flag? The computational kernel is quite a ball of spaghetti as it stands currently… The first step of course would be to get decent test coverage, and potentially also measure speed, binary size, etc.

1 Like

Yes, definitely would accept that kind of pull request.

When I remove the -std=legacy flag, everything still compiles, but gives many warnings that look like this.


  123 |  110      PC(I) = PC(I-1) + FNQM1*PC(I)
      |                                                                        1
Warning: Fortran 2018 deleted feature: DO termination statement which is not END DO or CONTINUE with label 110 at (1)

See this repo: GitHub - jacobwilliams/odepack: Work in Progress to refactor and modernize the ODEPACK Library

For the beginnings of an attempt to actually refactor odepack. Mostly from @urbanjost who used the SPAG tool to get it started. It is very much a work in progress but if somebody wants to contribute we are willing to accept help!

1 Like

I think that you may find more people willing to help if the refactored code were restricted to, say, F95+TR15581, with as few modules as possible in each project, and explicit interfaces being provided only when necessary.

With those restrictions, the refactored code could be compiled and debugged with Lahey/Fujitsu and Silverfrost, which are my tools of choice for debugging. Unfortunately, these same tools do not handle submodules, the availability of which can make reusing modules easier.

It is one module, if that helps. The individual procedures are in separate INCLUDE files for easier editing, which makes it appear otherwise. A few procedures not completely converted to be able to be in a module are still included into the single file at the end, which are part of the WIP aspects of the project.
INCLUDE was used to split up the source code as a module was desired but submodules, as you mentioned, are not universally supported.

There are a few uses of post-95 usage; The conversion package had options to restrict what the rewrite would write, so you could pick a standard level. Not sure if I added the newer features or if part of that came from the package without looking back through the history.

1 Like