open source scientific computing: my personal hell.

I’m in the process of learning AUTO, a numerical package for solving boundary value problems, continuing solutions of differential equations, and analyzing bifurcations in systems of equations. A quick Google search revealed a page which seemed to have a definitive answer of how I could get my hands on this program, directing me to a website hosted by Concordia University. On the site is a nifty timeline showing the development cycle of AUTO, also displaying how the bifurcation software has undergone several “affiliation” changes.

Weird that it’s shifting affiliations so seamlessly, I thought to myself– I couldn’t help but wonder who decides when it’s going to be passed off. However, I assumed that a couple of professors at CalTech and Concordia knew each other, and they agreed on swapping the application back and forth depending on who has a PhD student willing to work on the project. Naturally, I chose the latest version, downloaded it, and started playing around with it. It’s a fairly complicated package, with files like the following cryptic mass being the only user interface for articulating what you want to the machine:


2 1 0 1 NDIM,IPS,IRS,ILP
1 1 NICP,(ICP(I),I=1 NICP)
50 4 3 1 1 0 0 0 NTST,NCOL,IAD,ISP,ISW,IPLT,NBC,NINT
100 0.0 0.15 0.0 100.0 NMX,RL0,RL1,A0,A1
100 10 2 8 5 3 0 NPR,MXBF,IID,ITMX,ITNW,NWTN,JAC
1e-06 1e-06 0.0001 EPSL,EPSU,EPSS
0.01 0.005 0.05 1 DS,DSMIN,DSMAX,IADS
1 NTHL,(/,I,THL(I)),I=1,NTHL)
10 0.0
0 NTHU,(/,I,THU(I)),I=1,NTHU)
0 NUZR,(/,I,PAR(I)),I=1,NUZR)


Each of those numbers defines either very important quantities in your system, or tells the computer precisely what you want from its output. However, I’m not too concerned about that– after all, these are my colleagues in applied mathematics we’re talking about here, not computer scientists with time to spend on designing GUIs. This is a serious piece of machinery! So, I hunkered down, read the 232-page manual from cover to cover, followed demos and made test systems. I became fairly proficient in navigating the labyrinth of FORTRAN files and got what I need out of AUTO. Or, so I thought.

Last week, I met with my advisor and described how my efforts with a similar tool (written for MATLAB) had been going for our system, a retarded functional differential equation that can’t be handled by AUTO. My advisor replied that, with AUTO, he had resolved some of the issues tangentially related to my system, and proceeded to show me his code. I was shocked when I noticed it was written in C, rather than FORTRAN.

“How old of a version of AUTO are you using?” I asked, to which he responded that it was the latest version. I scoffed and thought that couldn’t possibly be the case, but after speaking with my colleagues in TAM I soon realized I was using a version of the program that nobody else was familiar with.

Had I stumbled on a beta version? Where was this other program? I sleuthed google for a bit and came up with only this site. Oops, that’s not it– that’s just its old SourceForge page. Ahh, here it is. The official source directly from the author. No, wait, that’s old and there isn’t even an index to the directory. OH OH HERE IT IS! Hey, what’s it doing in the AUTO-07p (FORTRAN software) repository?

Open source scientific computing is on a different plane of evil from those functionally-unsupported packages out there, like XMMS. Having worked in an IT environment that was reasonably sane, I have come to expect and appreciate the process through which software evolves. Someone has an idea to solve a problem, and a scope is determined for what the first version will accomplish. A proof of concept is created– which soon turns into a beta (or several betas), and inevitably a product is finished and released. Feedback is built into a list of “bugs” and “feature requests,” and developers continue to maintain the software staying reasonably close to the initial framework and code base. Sometimes a major rewrite is necessary, e.g. when the organization is switching languages, but documentation holds the whole process together.

I’ll introduce to you a completely separate scenario. Imagine someone has an idea to solve a problem, and it seems to be about the size of a PhD thesis. This fellow happens to be a graduate student, so he sells the idea to his professor, and in 1976 a project is began to write the application– in FORTRAN. Being that he’s really only writing the application for his dissertation, the only easily-accessible and complete documentation is stored in hardcover bindings at his institution. The software is released to the wild, where some people zealously continue its development. Years later, C becomes a dominant language and another PhD student takes it upon herself to re-write the package. However, the development branch for the FORTRAN version lives on by folks who just can’t let go– it was killed, but just wouldn’t die. It’s zombieware in a new sense of the word. This same story goes for a host of other applications, like Macsyma/Maxima. At least they had the good sense to change the name of the package to signal the divergence.

And now, if you will excuse me, I have to go figure out just how divergent these two applications are– and potentially re-learn all of the subroutines for AUTO in C (also known as AUTO2000, whereas the newest AUTO is named AUTO-07p. What iterative naming scheme?).