Showing posts with label computing. Show all posts
Showing posts with label computing. Show all posts

Thursday, July 23, 2009

Nerdy Addictions

I learned something about myself: programming is like mainlining heroin. Okay, I've never actually mainlined heroin, but I have seen the movie "Trainspotting," which is a sad but excellent portrayal of heroin addiction (in my very amateur opinion). I just got into a small programming task, and every day for the last 2 weeks I would blow off other work in order to get back to debugging. I had to find this error and make this work, and nothing was going to stop me. Okay, perhaps it’s not quite as bad as heroin, as I did remember to prepare and give a presentation to the summer undergrad students last week. But it is a short-term addiction in that I felt physically drawn to the code and the output files, studying them to find the clue that would solve my puzzle. I am glad the task was manageably small, so that closure could be reached without too much time consumed.

You see, I have not had a good chance to make modifications to my main computer code, myself, in a few years. My students (grad and undergrad) have been working on it, doing the things I used to do myself. Helping them learn how to make these changes usually takes more time than if I just did it myself, but that is no longer my job. I am supposed to educate others, and so hiring these people and spending time with them, to slowly do what I could do faster, is what I do.

Except this month. I laid out a long list of things to do this summer, and programming a new feature into the code wasn’t on the list. As I was cleaning off my desk recently, I came across a printout of an email from a coworker here. It was a mid-cycle review of one of his larger grants, on which I have a very small role. Within the review was a recommendation for a specific code modification, and it even suggested the reference for easily making this change. I had printed it out thinking that I (well, actually, one of my students) should incorporate this change, because it is a change directed at my part of the big project. I sat there staring at this sheet of paper and finally I decided: I would do it. Myself. Right now. Nothing else was that urgent that I couldn’t push it off for a few days, which is a how long I figured this would take, even with the times two factor on my estimate.

It is now 2 weeks later, and I am done. Success! This programming task I undertook so completely absorbed my attention that I didn't do much else and ignored many things until I reached the end. I feel like 2 weeks of my life have disappeared, and all of those things I was supposed to be doing are still waiting for me to do, only now I have 2 weeks less to work on them. I can't afford to do that very often, or I will get into serious trouble.

But I succeeded at a programming task. I’m pretty pumped up right now. I need another hit. No, I can’t go there! I have proposal deadlines approaching!

Tuesday, July 21, 2009

Crank-Nicolson Scheme

I’m pissed off. The f*ing Crank-Nicolson scheme for numerically solving diffusion equations isn’t stable. All of the textbooks state that it’s unconditionally stable. Liars. The fine print on this stability claim is that this unconditionality is for a constant diffusion coefficient. Large gradients in the diffusion coefficient can cause oscillations in the solution. Another issue is that there is a time and space step criterion on its stability. If the time step is too large relative to the spatial step, then oscillations appear. Another problem is that if the diffusion coefficient is too big, then the scheme tries to rearrange the result too much and again introduces oscillations. The net result is that the solution gives negative and/or very large values and the code crashes. I am now in search of another numerical scheme that can handle my large, spatially varying diffusion coefficients and nonuniform spatial grid. I have wasted nearly a week only to discover that my code was working perfectly and doing exactly what I was telling it to do: oscillate until it blows up.

Argh!

Tuesday, July 14, 2009

The New Mac

Where have you been all of this time, Intel processor for the Mac? I love you!

I have a computer code that I use as a big part of my research. It solves how electrically charged particle move through a region of near-Earth space. It’s a code that others began almost 2 decades ago and I am now the keeper of this code (let me clarify: I am the keeper of the version of this code at my university, as there are other versions out there as well, with different keepers).

It’s solving a time-dependent set of equations, so a typical simulation requires initial conditions for the start-up and then boundary conditions for the time interval of interest. I like to look at storm conditions in near-Earth space, so a typical simulation is usually a day-long interval, and often times I would run a 4-day interval, to capture the quiet time ahead and behind the storm interval.

When I got the code 10 years ago, it ran about 10 times slower than real time. Yes: to do a single storm simulation, I had to wait over a week for the result, sometimes a month. This slowly improved over the years as I kept upgrading my computer. I recently replaced a G5 Mac with a new Intel-based Mac. On my old Mac desktop computer, it used to run about 3 times as fast as real time. This was a big improvement over the previous machine, as it was the first time it passed real time speed barrier. On the Intel machine, it’s now 12 times faster than real time. Not only that, but my new Mac is a dual-quadcore machine, with 8 CPUs inside of it. The timing numbers above are for serial processing jobs. My old Mac was a dual processor machine, and I didn’t like to run it in parallel mode because then I couldn’t much else with the machine until the run was done. This is no longer a limitation. Spreading the run over 4 processors (leaving plenty of processing power for other things) means that the code is now 50 times faster than real time. I can do a 4-day simulation in 2 hours. Oof-da!

For a long while I had been hesitating with code development because it was so painful to wait for results. Not anymore. I can now dive back into it. Now, I just have to remember FORTRAN again. Oh yeah, and find time to actually program.