Proposal: maintain packages collectively at https://github.com/fortran-lang

[certik]

Fortran has many legacy packages, living at netlib and other places. Recently people have started resurrecting them. Initially people just provided a modern build system and ensured they build with recent compilers, examples of that would be:

• https://github.com/certik/minpack

Lately, people have started providing fpm build system for them, an example:

• https://github.com/ivan-pi/LINPACK
• https://github.com/ivan-pi/y12m
• https://github.com/ivan-pi/SMMP
• https://github.com/ivan-pi/fortran_lsp

Proposal: I propose that we allow to move such packages to the https://github.com/fortran-lang organization at GitHub.

Here is how Rust does it:

• https://github.com/rust-lang

They have the core Rust packages (such as the compiler, package manager, etc.), but then they also have just Rust packages that they maintain collectively.

For Fortran this is even more natural: there are hundreds of existing packages / libraries / tools in Fortran that are abandoned and many of them are high quality. I can attest for example that both MINPACK and FFTPACK are high quality packages, FFTPACK for example even to this day competes very well in terms of performance (often within a factor of 2x against optimized FFTW). By maintaining them as a community under the fortran-lang organization we can effectively resurrect them, making them readily available using fpm and give them visibility and support as a community.

[certik]

Another thing to discuss is what kind of packages to host. I would propose any package that is abandoned and we are just resurrecting it. For packages that already have an active home somewhere else, such as https://github.com/opencollab/arpack-ng, we can leave those there (although they are certainly welcome to move under the fortran-lang umbrella if they wanted).

Finally, for new packages that somebody writes from scratch, we will have to create some criteria, perhaps having at least 2 contributors or something like that.

[awvwgk]

I like the idea of having community maintained Fortran packages here at @fortran-lang. What are the criteria to have an officially @fortran-lang hosted Fortran project (maybe even independently from being resurrected or newly created)? What minimal standards do we set for such a project?

[awvwgk]

Rust also has a https://github.com/rust-lang-nursery to create new Rust packages. For now there is probably no need for such a staging area in @fortran-lang. Also, we might not want follow this line of thought too closely when deciding on a namespace for resurrected Fortran packages.

[ivan-pi]

I added two more packages to your list, also from Netlib with added fpm support.

While I would like to see these codes flourish again, there are some challenges with the old Netlib codes:

• many have gaps in their support for different real kinds (precisions are either single or double, sometimes both)
• some require refactoring due to non-standard Fortran practices
• most of them come with no interface module. Maybe a module with the external interfaces and potentially even intent attributes should be a minimum before they can be accepted into the collective. (:cry: maybe I will drop LINPACK.)
• documentation are just plain old text files
• licensing terms are often not clear. While some are in the public domain, this is not good enough in certain jurisdictions.

[awvwgk]

Keep in mind even on GitHub codes can die (to extend the where Fortran codes go to die metaphor), I have seen plenty of those already and also resurrected some.

Resurrecting a project is one thing, but making it useful is much more difficult, good documentation and examples are required for ones, availability is another issue (this will be solved by fpm). Than there might also be a performance issue with some of them. Let's take LINPACK as example, which has been rightfully superseded by LAPACK. There is almost no reason to built a project on LINPACK today, which could use the LAPACK API instead and profit from tuned libraries like MKL as well. If we resurrect a project based on LINPACK, what are the performance implications for such a project?

[certik]

Good points @ivan-pi and @awvwgk. I am glad you raised them.

Perhaps we should aim to only include projects that will become useful. As an example we can maintain an fpm package for LAPACK (whose upstream sources would stay at https://github.com/Reference-LAPACK/lapack).

[awvwgk]

Perhaps we should aim to only include projects that will become useful. As an example we can maintain an fpm package for LAPACK (whose upstream sources would stay at https://github.com/Reference-LAPACK/lapack).

LAPACK is special in many regards, I would go so far to say that I never want to include LAPACK as fpm package but always by linking against an external library to actually make use of tuned libraries like MKL (see https://github.com/fortran-lang/fpm/discussions/330 for a related discussion).

[certik]

@awvwgk yes, that was a bad example, indeed I would like a special support for Lapack in fpm (#368) as well as for MPI (#354).

FFTPACK would be a better example then. Or ARPACK (with upstream sources at https://github.com/opencollab/arpack-ng).

[ivan-pi]

Let's take LINPACK as example, which has been rightfully superseded by LAPACK. There is almost no reason to built a project on LINPACK today, which could use the LAPACK API instead and profit from tuned libraries like MKL as well. If we resurrect a project based on LINPACK, what are the performance implications for such a project?

I agree new projects don't need LINPACK at all. My interest in the LINPACK routines was primarily due to a calling library by Sabine Van Huffel (see http://www.netlib.org/vanhuffel/readme), author of the book on Total Least Squares (TLS) Problems (the book has 1992 citation according to Google Scholar). According to her readme file, the routines have a LINPACK dependency. Ideally, sooner or later me or some other interested Fortranners would replace the LINPACK routines with the equivalent LAPACK ones (I have done this before in a different project).

Just for comparison both Julia and Python both have easily accessible packages for TLS:

• TotalLeastSquares.jl
• scipy.odr (wrapper of ODRPACK from Netlib)

I agree with both of your comments about LAPACK requiring special integration. This will also be crucial once we get to the point of calling LAPACK in stdlib.

[awvwgk]

Another package that might be interesting here is MUDPACK, this is currently actively used in @dftbplus and redistributed with the code base. There would be at least one user for a resurrected MUDPACK.

Other legacy projects are probably used in a similar fashion, embedded or redistributed in existing modern code bases.