Wednesday, January 20, 2010

control-z bg

I guess I've been writing simulations for half my life. I was eleven or twelve when I first started meddling with QBASIC. My dad would bring a laptop home from work, an old notebook with a monochrome screen and a trackball. Since it was a work computer, we weren't allowed to install any games on it, but it had QBASIC, so I figured I could write my own. It turns out that writing computer games isn't as fun as playing them, but I started programming, anyway; it's fun!

When I was sixteen, I started working at a particle accelerator lab with the Army Research Lab. It wasn't a huge Fermilab kind of thing, our accelerator was a small, linear thing. We'd shoot ion beams at materials to see what would happen. I wrote a little QBASIC program to help design ion beam sweep patterns that would leave even coatings.

Later, my boss wanted me to analyze some data from a simulation. I spent the summer learning C so that I could write code that would do all sorts of things with the data. It was my first time using Unix; I was using an old SGI box.

Unix is paralyzingly unintuitive, and this machine didn't have a neat desktop environment installed. It was running X and some sort of window manager, but not much else. I had to work mostly from the command line. A command line is a sort of typewriter way of interacting with the computer; you type a command and hit enter, and the computer types something, giving you the information you asked for, for example, and then you can type again. When you start a program that runs in a window, I was using an application called nedit, the computer locks the command line. I couldn't type anything else! I felt panicked! My boss taught me: hit control-z to interrupt the program. That stops the program, so you then use the command bg (for background) to start the process up again.

This is the sort of thing that most people never need to know, but that Unix users have to do every day; at the time, it seemed like I was doing really fancy geeky stuff.

My boss introduced me to other things, Unix and Mozilla (that was before it was Firefox).

In grad school, I've done computational research; I use fancy numerical methods to study how fluids interact with membranes on the micro-scale. I've written code to run on clusters of computers, I've re-worked a couple of things in the code that solve partial differential equations.

Today, I installed a program, VisIt; it makes pictures of simulation data. I mostly use programs I can start up by typing a few things, and leave them running on a server; I download the data and look at it with Matlab. VisIt popped up a little window. I hit control-z bg.

Tuesday, August 25, 2009

Numerical modeling and computer programming are different jobs, sort of

I write in Fortran. Fortran is basically not taught in schools anymore, nor should it be. It's an ugly, outdated, backwards programming language. My code has a two-dimensional array called number (hint: everything in my code is a number). It's barely commented. There are redundant subroutines that do subtly different things that should probably be combined.

There are no buttons or widgets or dialog boxes. There isn't a prompt you can type things into. It doesn't even have a command-line interface. To run the code with a different set of values involves editing Fortran source code and recompiling. The code is its own user interface.

My friends in computer science hear about this and shudder and moan and gnash their teeth. I did, too, when I started my job, because, unlike most mechanical engineers, I have read a lot of books on how to program properly. I read a lot of articles about coding standards. I've gotten red in the face over how curly braces should be used in C. According to Good Programming Practice, my code I use for my research is backwards, barbaric, and ugly. It's like your racist uncle.

The code is exactly how it should be.

Research code is completely different from commercial code. I scrawl out notes to my roommate telling him yes-I-know-I-left-a-pile-of-dishes-in-the-kitchen-I'll-get-to-them-soon-honest-I-promise, but spend weeks revising material to be published. Research code, designed for a small handful of technical, intelligent, skilled people who want data right now, I mean now! Commercial code, used by thousands, needs to be less buggy, run on different systems, and be maintainable. It at least needs an interface.

At least, that's what I was told after I started doing graduate research in numerical modeling. That's what everyone tells you to do. I have one professor who joked about how you never read manuals, you just copy-and-paste your old code. There are places in my code where I have a list of if statements where I should use a select case instead, and didn't, because it was easier to write a few extra lines of code than to turn around and pick up the manual.

I'm starting to reconsider this school of thought, though. I started to think that research code should meet a higher standard when I got frustrated, recently.

In my code, I simulate fluid-structure interaction. For my research, I look at capsule dynamics, that is, the physics of elastic membranes in fluid flows—think balloons. I had been looking at test cases involving one capsule, and for me to look at two, that would mean copy-and-pasting the initialization for the first capsule, changing the code that tells the second capsule where to go. I also need to change array sizes everywhere in the code.

I'm fed up with code that's obnoxiously difficult to work with. It stifles creativity and innovation. Even if I'm the only person who will ever see my code, I'm going to start writing good code. I have a rigid testing protocol, starting now. I'm using version control several times a day, rather than a couple of times a month. I'm writing documentation. I'm making a total overhaul to the code.

I think I might write a version of the code in C++ because Fortran sucks and. I haven't written C++ since I was seventeen, and I work on Fortran every day. Last week, I decided to play with some old code and in minutes I fixed a seven year old bug in some linked list code I'd written for practice. C++ just makes a lot of sense, and Fortran doesn't.
Blog Widget by LinkWithin