Occasionally when using Linux (or Mac OS X) I’ll notice a tongue-in-cheek output message from a utility. Today, it was ‘file‘, a program that uses magic numbers and other tricks to tell you about the contents of a file:
[brock@stilgar][Darwin]-(~/Workspace/RvPacing/bridge/flma2memfem)-> file bridge_w_surf.flma
bridge_w_surf.flma: ASCII text, with very long lines
[brock@stilgar][Darwin]-(~/Workspace/RvPacing/bridge/flma2memfem)->
Emphasis mine. Thanks for the commentary, file.
ADDENDUM: Just now, tar gave me this little message because I forgot to provide some source data:
[brock@stilgar][Darwin]-(~/models)-> tar cfjv bridge_iso.tar.bz2
tar: Cowardly refusing to create an empty archive
Try `tar --help' or `tar --usage' for more information.
Imagine this: You have two text files full of information, with one data entry on each line. You want to find out which lines occur in both files. Now, if the files are mostly the same, it’s probably best to use a program called diff. However, if the files are mostly different, you can use this little incantation:
cat file1.txt file2.txt | sort -n | uniq -d
This will join file1 and file2, sort the joined data -numerically, and display only the lines that are not unique (uniq -d).
This came in handy for manipulating electrode files today. Our electrode files just contain lists of node numbers. The simulator gets unhappy when you try to do things with overlapping electrodes, so in this way we were able to remove the offending overlap without too much trouble.
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.
If you are a user of the GNU Image Manipulation Program (GIMP) on OS X, and you’ve upgraded to Leopard, you’re likely to run into some snags. You should instead go here to update your X11 installation, and then here to get the appropriate version of GIMP. Note that this is the new 2.4 version, with a lot of improvements from 2.2. They also have a more “edgy” and modern-looking icon for the app.
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.