Category Archives: Science

Science

The Engineer’s Conscience: Doing the Right Thing

There’s a long and (two-year-) old screed over on K5 entitled How I Was Saved ostensively about the proper way to write C++ code. I actually found it in my trove of old bookmarked to-read articles using Readeroo. In it, there’s a very good, very penetrating thing said about the responsibility of engineers to do the Right Thing:

Because an engineer named Roger Boisjoly didn’t trust his conscience, seven brave and innocent people died. No, he followed standard procedure, by reporting a safety risk to his superiors, then trusted them to do the right thing, despite the fact that they obviously didn’t heed his warning:

It got real cold one night when the Space Shuttle Challenger was being readied for launch. The Shuttle’s two solid fuel rocket boosters had been manufactured by Morton Thiokol in several sections. Rubber O-rings were used to seal the joints between each section, and covered with high-temperature putty to protect the rubber from the flames. But the rubber the O-rings were made of became stiff if it ever got cold. It wouldn’t flex as the sides of the joint vibrated in and out, so that the flames inside the rockets might shoot out through a crack, and make the liquid fuel tank explode.

Realizing the risk, Mr. Boisjoly filed a safety report with his superiors, yet despite the fact that they overruled his advice for fear of losing Morton Thiokol’s fat government contract, he did his duty to his company and kept quiet.

But he didn’t do the right thing when he realized the Challenger was going to launch to its doom. Why didn’t he ring someone up at NASA? We didn’t he go to the press? Why didn’t he crash his way into Mission Control, arms flailing and screaming “IT’S GOING TO FUCKING EXPLODE!”?

Because he might have lost his job? He probably would have, but I don’t think that’s why. Gotten arrested? No. I don’t know for sure, but I’ll hazard a guess: either because he trusted his company to do the right thing or because he didn’t want to get blacklisted. And because he didn’t trust his conscience, and go against orders – no, not even that – against standard procedure, he has these people to answer to, and their loved ones:

* Francis R. (Dick) Scobee (1939-86), Commander
* Michael John Smith (1945-86), Pilot
* Ellison S. Onizuka (1946-86), Mission Specialist One
* Judith Arlene Resnik (1949-86), Mission Specialist Two
* Ronald Erwin McNair (1950-86), Mission Specialist Three
* S.Christa McAuliffe (1948-86), Payload Specialist One
* Gregory Bruce Jarvis (1944-86), Payload Specialist Two

Someday you might be faced with such an awful decision. Most engineers don’t ever consider the possibility. I’m asking you to consider it now, ahead of time, so if the time ever comes, your mind will already be made up.

Preceding this is a tale of how the author learned to do things right from his father. I’m proud to say that I learned something similar from my father. He’s always been willing to put forth the time, effort, or money to do something the right way the first time, and that’s an example that’s served me well. I haven’t always been able to pull it off, and there have been times when I’ve forgotten how important it was. I suffered the consequences of cutting corners those times, and was reminded of the lesson. I’m just glad those reminders were not at the expense of someone’s life, much less the lives of seven people.

Float vs. Double

Someone in the lab recently came to me asking for help in diagnosing a strange problem. The time output from their program was drifting inexplicably — that is, they were adding a certain increment every iteration, but the time was changing by some value slightly different from that increment. It turns out that this was because they were using single-precision floating-point (a.k.a “float”) variables. The problem did not show up right away. In fact, it would not have been an issue were they not adding an increment so very many times.

To diagnose this problem, (because I haven’t dealt with this issue in a long while), I wrote this little piece of code:
Continue reading →

How I got our cluster to send me MMS movies of my simulations

As the models used in our lab become larger both in resolution (more detail) and gross size (bigger pieces of tissue), the time and effort required to visualize and otherwise check results increase. With the largest model currently used in the lab (mine), one short simulation produces 2.0 GB of uncompressed data. Compression gets it down to about 500 MB or so. That still means that — just to make sure the simulation ran correctly — I have to download 500 MB of data, load my model into a viewer of some kind, and load and view the data. This is not acceptable, especially since even loading the data requires a machine with significant graphical power and a large hard drive.

There are other ways to visualize our data. A little while ago (two years?), our programmers Rob and Umar put together an off-screen renderer for the IBVRE project. It’s based on VTK and coded in Python. It simply loads the model with views from all 6 sides, maps the data on to the surface, and then writes an image file.

I spent 12 hours Saturday resurrecting this software and tweaking it for my own needs. Now it just loads one view of my model, efficiently steps through a specified number of time steps (it did this very very inefficiently before), writing them all to image files, and then exits. I run this on the cluster with a script that joins all of the images into a movie, and then emails them to me.

I currently have the cluster email me when a job is done. I also have mail filters that forward these messages to my phone. However, I can now do better. I have integrated the rendering program with my cluster run scripts, such that the following happens. When a simulation is finished, the visualization program is run and dumps images of all of the time steps. They are then joined to make a movie, emailed to me, and emailed directly to my phone. Thus, when the simulation is finished, I not only get an email notification, but I can review the video right on my phone.

If you’re not a geeky type, this may not impress you. To me, it is the very apex of cool. Enough so that it drove me to stay at work for nearly 13 hours on a Saturday. Here’s a sample video:

Now, instead of downloading 500 MB or more to a high-powered workstation (or let it limp on my laptop) to check the outcome of a simulation, I can have a 1 to 4 MB video automatically sent to my mobile phone and watch it wherever I am.

It all begins when the gates open.

Maria has an excellent little vignette about nerve firing (which is very very similar to cardiac cells firing) over at intueri. Here is an excerpt (whose prose is typical of her excellent writing):

Sodium ions flood into the single brain cell through the gates of channels linking the exterior and interior of the neuron. Other channels along the length of the cell follow suit, opening more gates to allow more sodium ions in. A deluge of positively-charged atoms overtakes the single cell.

Other channels follow the precedence, though they selectively permit calcium, not sodium, ions to join the influx. The excess positive charge soon beckons the potassium channels to open and, with gusto, potassium ions flee from the interior of the cell.

Using UNIX (and Linux) for Research in silicio

There is a rank list of the most powerful computers on the planet: Top500.org. (It looks like they’ve recently done a site redesign for the better.) Statistics on these computers are available here. Of the top 500 most powerful computers on the planet, a measly 1.20% run a non-UNIX operating system (OS). 76.20% run an unspecified Linux (compared with, say a certain version of Red Hat or SuSE linux). According to the overall family rankings here, a total of 85.20% run some variant of Linux. The remaining operating systems on the list are all various UNIXes, including BSD and Mac OS X.
Continue reading →