How can a large, Fortran-based number crunching codebase be modernized?

Question

A friend in academia asked me for advice (I'm a C# business application developer).

He has a legacy codebase which he wrote in Fortran in the medical imaging field. It does a huge amount of number crunching using vectors. He uses a cluster (30ish cores) and has now gone towards a single workstation with 500ish GPUS in it.

However where to go next with the codebase so:

• Other people can maintain it over next 10 year cycle
• Get faster at tweaking the software
• Can run on different infrastructures without recompiles

After some research from me (this is a super interesting area) some options are:

• Use Python and CUDA from Nvidia
• Rewrite in a functional language. For example, F# or Haskell
• Go cloud based and use something like Hadoop and Java
• Learn C

What has been your experience with this? What should my friend be looking at to modernize his codebase?

UPDATE: Thanks @Mark and everyone who has answered. The reasons my friend is asking this question is that it's a perfect time in the projects lifecycle to do a review. Bringing research assistants up to speed in Fortran takes time (I like C#, and especially the tooling and can't imagine going back to older languages!!)

I liked the suggestion of keeping the pure number crunching in Fortran, but wrapping it in something newer. Perhaps Python as that seems to be getting a stronghold in academia as a general-purpose programming language that is fairly easy to pick up.

See Medical Imaging and a guy who has written a Fortran wrapper for CUDA, Can I legally publish my Fortran 90 wrappers to Nvidias' CUFFT library (from the CUDA SDK)?.

Answer 1

The demands you have put actually put Fortran at the top of the list, for problems like this:

a) number crunching
b) parallelable
c) it was and still is the de facto language taught outside of CS studies (to engineers who aren't professional programmers).
d) has an incredible(!) industry backing, number-of-industry-grade-compilers-wise, with none of the vendors showing the least signs of abandoning that branch. One of Intel's representatives not far ago revealed that sales of their Fortran products are higher than any other in their development tools.

It is also a language which is incredibly easy to pick up. I don't agree that it takes time for bringing research assistants up to speed. My first textbook on it had no more than, oh I don't know, 30 (?) pages of sparse printed text. It is a language in which after learning 10 keywords, one can write medium-sized programs. I would dare say that those 30 pages written in default Word text would make a more than comprehensive "Fortran manual" for most users.

If you're interested in CUDA, you might want to check Portland Group's compiler, which supports it. I'm not familiar with the finer details, but people generally talk of it with praise.

Apart from that, for paralleling programs you have available OpenMP, MPI and now the upcoming (and long awaited) co-arrays, which Intel's compiler has recently implemented. To not waste words, Fortran has a very fine gamma of "libraries" for parallelizing programs.

Industry standard numerical libraries are developed for it foremost, other languages following more or less in the function/routines portfolio.

All that being said, I would however (depends on when it was originally written) recommend if it is, let's say, F77 code or older, rewriting it partially through time to newer dialects - F90 at least, if possible with F2003 features. A paper / thesis on that topic was recently published (medium-sized PDF file ahead). Not only can that, if done properly, ensure portability across multiple platforms, but will also make it more easy for future maintenance.

p.s. As far as "future maintenance" goes, just an anecdote which I sometimes like to mention. While writing my thesis, I reused some code from my mentor, written 35 years ago from the time of writing. It compiled with only one error; a statement missing at the end, due to copy-paste mistake :)

---

@DaveMateer (reply to comment) - I'm going to make a comment in the following which may be a bit impolite, but please don't take it the wrong way, for it is in the fair intentions.

It seems to me you're tackling this "problem" in the wrong way. What I mean in a few short points (for it is very late in here, and my ability to make up readable (let alone comprehensible) sentences leaves me after 10p.m.)

a) You mentioned you're trying to minimize extra coding time, yet you're considering a rewrite from a language specialized for numerical computing to one from a colorful choice of languages, if you'll pardon my expression

• some of which don't have support for multidimensional arrays, amongst other things
• most of them are unsuitable for heavy numerical work (of parallel processing capabilities of Haskell and Hadoop I admit, I know nothing about ... but have never heard them even mentioned in those circles)
• it possibly has been tried, but I've never heard of a rewrite from Fortran, a language for discretized problems, to a functional language
• there has been a discussion recently on comp.lang.fortran (try searching through Google Groups) on the aspects of scientific computing "in the cloud"
  (wouldn't like to demotivate you, but to be fair, no one was really sure what that term even represents, let alone had an example of a successful application. Most people agreed that potential exists, but so far they're happy the way things work for now.). A lot of problems are not suitable for that kind of parallelisation either.

b) What would be the costs of such a rewrite? People/hours.

c) Correct versions of the libraries to compile...- is a problem in any language that cannot be avoided, however you look at it.

d) I've heard of Python (a nice language really) used in parallel applications on a few occasions, but its penetration of that market still doesn't seem to be rising, and its ever changing nature makes it a very poor choice for a long term project (think backward compatibility). Some people like it very much as a "glue" language.

Ugh, if I think of anything else, will add it tomorrow. Gotta get some sleep...

Answer 2

I doubt Fortran will ever die -- it has such a large legacy of software and libs written in it that people are still working on it, only stabilizing this situation. Moreover it is still a very good language if you don't want to do anything more than number crunching -- syntax is very elegant and logical, plus the compiler can easily guess what is happening. Thus it is guaranteed that any new hardware accelerator technology will support C, Fortran and some kind of OpenCL (when it would finally converge to something solid).

So I would say you should just clearly separate numerical part, leave it in Fortran, make clear binding and write the rest in whatever you want.

Answer 3

Python is indeed gaining a lot of traction in the scientific computing community (for a somewhat outdated view, see volume 9 number 3 of CiSE). I think a Python/Fortran hybrid is an excellent way to go. In order to take advantage of all those GPUs, you could use PyCUDA or PyOpenCL.

I'm a mathematician who analyzes and writes numerical solvers for partial differential equations. I was recently in a similar situation to your friend's; the Fortran 77 code in question is the well known Clawpack software. We rewrote the top level code (all the parts that don't need to be fast) in Python and used f2py to automatically wrap the low-level parts.

The really powerful result of this is that we were then able to almost trivially connect the hybrid Python/Fortran code (dubbed PyClaw) with the parallel library PETSc, creating for the first time a scalable parallel version of Clawpack that performs well on 65K cores. All of the parallel code that we had to write is contained in less than 300 lines of Python. We're now solving problems that couldn't possibly have been tackled just with the legacy code. Just as importantly, it's now much easier for new users to pick up the code, since Python is such a friendly language and almost everything can be modified at run-time rather than compile-time.

If you want to see more details of our approach and results, we have a paper on the arXiv.

Apologies for the self-advertisement, but it seemed that my personal experience would be relevant here. If you would like to hear many more ideas, you could post this also on the new http://scicomp.stackexchange.com.

Answer 4

I am currently in the process of updating an old FORTRAN95 codebase to be used on modern industry environments as the previous version will only run on Windows2000 machines at the latest. The FORTRAN codebase itself performs a large amount of number crunching involved with irrigation simulations.

So what I am doing is instead of re-writing the FORTRAN in a more modern language I am simply using a commercial compiler called Silverfrost FTN95 to compile the FORTRAN codebase to a .Net 4.0 library which I am using as the backend of a WPF application. This way I do not run the risk of bringing knew bugs into the simulation code and I am modernizing it by moving the codebase to the .Net 4.0 framework so it will run on more modern environents.

But depending on how big your simulation is you might want to just simply re-write the whole thing in a more modern language such as C#, i myself am planning to do this once I have a running version of the simulation to compare output with.

Hope my expieriance helps, Thanks, Alex.

Answer 5

I am currently in a situation very similar to your friend's. I am also desperate to "modernize" my 40-something KLOC Fortran-77 legacy code. And despite that Fortran is still considered the king in number crunching applications, I would like to say that all is not lost. (What follows is rant-ish so bear with me).

Just because Fortran is the best language for numerical code doesn't mean we have to carry this huge baggage of a messy, complicated code with us all the time (Yes a Fortran code is bound to be messy, especially Fortran-77 that is a language that has literally no regard for software-engineering, when it crosses a certain KLOCs). Those who advocate Fortran for number-crunching forget the general observation that when you do performance analysis of such codes, it's only 5% or 10% of the code that is performance intensive and for the remaining 90%+ Fortran is a useless overhead, just there to make your life as a "software engineer" a living hell.

When you are moving to Fortran-90 from Fortran-77, you're essentially willing to trade-off performance with language features to an extent. Fortran is a powerful number cruncher primarily because of Fortran-77. You might say Fortran-90 is as fast, but the kind of optimization issues compiler writers had to deal with while adding Fortran-90/2003 features and still keeping Fortran-77 performance are not much different from the issues C compiler writers had to deal with (and as a result C is considered as fast too, not to mention C allows inline-assembly as well). So why not start adding C code bit by bit (instead of Fortran-90) into a Fortran-77 code. My code already has pieces in C and pieces in Fortran-77 and it works great subject to some issues like passing strings, zero-indexing/one-indexing etc. But the advantage I get from C, in terms of File I/O, string manipulation, better community support, more familiarity among new programmers etc, etc, would I get that from Fortran-90?

I'd go one step further. Even C (and definitely Fortran-90/95/2003) is too low-level if you want a nice "humane" interface to a number crunching code. I'm thinking of moving to a Python-Fortran-77 or a Python-C hybrid. A code in which 90% of the code is Python (including Numpy, Scipy, plotability, and all that sweetness) and only the performance intensive 5%-10% remains as Fortran-77 or C code.

Answer 6

I was lead dev on a project from 2001-2003 which ported a 100KLOC windows application from FORTRAN to C#. It was a number crunching application which had its own custom GUI bindings to Win32 libraries. The port to C# and WinForms made the management of the code far simpler and gave everyone a richer development environment in Visual Studio. There was a fair bit of resistance early (especially in terms of format statements), but in the end it was definitely worthwhile.

In my opinion it makes sense to bite the bullet and get rid of the maximum amount of FORTRAN code possible. Speed was never an issue - initial tests running code in C# compared to FORTRAN found the performance difference to be negligible, even though C# is running managed code. Your needs with vectors may be a bit different however, and having a minority amount of FORTRAN code left over would also be acceptable.

Another reason to do it is of course the long term availability of people with FORTRAN experience who can maintain your code as compared to C# developers. Also, it helps team morale to be working in a modern, well supported language.

Answer 7

I've been told that in many contexts, MATLAB is replacing FORTRAN for scientific computing application. Not only is it modern and high-level, it's also pretty fast at what it does. A lot of developers working on medical imaging software use MATLAB already, so it has several libraries dedicated to medical imagining. This means you will find both tools and domain-expert support if you go with MATLAB.