Modernizing Arpack

1

FIrst of all, kudos to the lfortran community for this effort!

A little offtopic: one modernization project which might have a very big impact also beyond SciPy could be ARPACK. AFAIK, ARPACK is basically everywhere until today (R, Matlab, Scipy/sklearn, …) but running it on top of different BLAS/LAPACK implementations reliably is just never ending pain (especially for complex types). See for example how in this discussion on SciPy a possible deprecation is proposed for the first time. Recently, PROPACK was added to SciPy which causes even more headache.

I guess that this might be an even bigger undertaking than MINPACK but would like to hear some opinions of Fortran aficionados.

4 Likes
2

@dschmitz welcome to the forum!

I split your topic from minpack, since this seems like a separate topic.

There is arpack-ng: GitHub - opencollab/arpack-ng: Collection of Fortran77 subroutines designed to solve large scale eigenvalue problems. that seems relatively well maintained. I use it for a “modern Arpack” version.

2 Likes
3

Looks like arpack-ng is maintained, but not really modernized (FORTRAN 77, GOTOs, etc).

2 Likes
4

I remember ARPACK caused a lot of issues when I was using Julia. Is it too large to modernize?

5

My list of Fortran codes includes

which I have not tried.

2 Likes
6

I still see many “GOTOs and stuff” there (as an example, look at PZNEUPD).

1 Like
7

Hi @rgba, welcome to Discourse!

In PZNEUPD, go to is used to jump to end of the routine. Typically, older codes would use this pattern to handle exceptions at the end of the routine. Here the jumps could be replaced with return statements. There are several other things which could be improved here, the question is just who is willing to volunteer their time or sponsor the work financially.

Speaking of goto, I can recommend the following reading for a more balanced view of how good (or bad) it is:

2 Likes
8

Thank you!

I was not implying that the code is bad, just pointing out that is not really modernized yet :slight_smile:

Anyway thank you very much for the links, as someone who took his first coding lecture in 2013 and seen the first fortran line in 2020 I knew very little about old practices. I found all the reads quite informative and fascinating!

9
4 Likes
10

Good talk. I am hoping in the future we’ll be able to use LFortran to do the automatic translation to Julia.

3 Likes
11

Indeed an interesting talk. The same modernization steps could (should!?) be followed in Fortran too:

  • remove global state for thread safety
  • remove goto’s and other deprecated control flow constructs for clarity
  • address reproducibility of random number generator
  • replace assumed-size arrays with assumed-shape arrays (potentially controversial due to C interoperability)
  • improved norm computation with intrinsic norm2, potentially in extended double (80-bit) or quadruple precision (128-bit, software emulated) if need be

Speaking of automatic translation to Julia, given that Julia supports reflection and introspection, and you can also access Julia’s AST, wouldn’t it be possible to write a transpiler which generates Fortran from Julia? You can already transpile Julia to C or compile it to WASM.

I can certainly imagine a future where any time I find a useful Julia code, I transpile it and include it in my existing Fortran programs. Julia has been profiting from existing Fortran libraries, so doing it the other way round should be possible too.

5 Likes
12

If anyone’s interested, here are some links to David Gleich’s pages and GenericArpack.jl:

  • 2021-04-21: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 1 - Goals
  • 2021-04-22: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 2 - Overview
  • 2021-04-29: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 3 - First routine
  • 2021-05-13: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 4 - Checking against libarpack
  • 2021-05-18: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 5 - Understanding Ref
  • 2021-05-26: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 6 - Sorting Take 1
  • 2021-06-17: Me on learning about save variables in Fortran and accessing them from Julia. (Part … something … in my ongoing segment on porting ARPACK to Julia)
  • 2021-06-24: ARPACK Sorting Take 2 (Part … blah in the ongoing series…)
  • 2021-06-28: LAPACK’s random number generators in Julia (part … blah … in work to port ARPACK to Julia.)
13

Why bother translating back? If the Julia is simple enough to automatically translate to fortran, you can probably just use StaticCompiler.jl to compile the julia to a binary directly.

14

That would be fine too. I see the StaticCompiler.jl package originated from the need to include some code in Python. In the case where binary linking is possible, it would be nice to at least to automatically generate the Fortran interfaces. :slight_smile:

More generally, some of the reasons to translate to Fortran are the unmarked checkboxes in the Features roadmap · Issue #59 · tshort/StaticCompiler.jl · GitHub. To put it briefly - platform portability.

Fortran compilers which can run on Windows include Intel Fortran, GNU Fortran (via cygwin, mingw, or mingw-64), NAG, Silverfrost FTN95 (targetting .Net), Absoft, just to mention a few out of several others.

Other reasons would be project-specific restrictions and guidelines, etc… I could probably find a few more perma-computing related reasons: “If the new software no longer runs on old hardware, it is worse than old software.”