« Gazizza, Bill | Main | I had a big history exam the next day and the only copy of the Fedaralist Papers that I had was *abridged*! »

Sir, we can't eliminate the line item for our oxygen supply

Today was the Thunder over Louisville festival.

It's a big air show and enormous fireworks display over the Ohio River between Indiana and Kentucky. Our house is about 15-20 miles from the river; as I was out in the garage building our new gas grill, I could see a bunch of the military planes fly by on their route to the show. I saw some tankers and some fast movers (have no idea which; I'm not a Zoomie). It was actually kinda cool.

I didn't see my old Apache unit on the TV coverage, but that doesn't mean they weren't there. They've apparently been in the show in years past (I still haven't made it to a show yet; perhaps next year). They had the B1-B Lancer close the military part of the airshow; the TV coverage simply didn't do it justice. That is one Big Friggen' Plane. The only time that I have seen one was at the Chicago air show last two years ago, and it was enormous. Louder than a hum-vee stuck in the mud, too (and that's loud).

We watched the fireworks on TV, too. It was pretty amazing and I'm pretty sure that the TV coverage didn't do it justice, either. The close the bridge over the Ohio river and shoot off fireworks from both there and barges in the river. By my watch, the show was about 25-26 minutes of nonstop fireworks. Amazing stuff.

And just think -- someone probably wrote software to design (and execute!) fireworks shows. You gotta take into account ignition time, launch time, height and flight time, explosion time, fade time, timing to the music, etc., etc. Think of the database of ordinance that drives that simulation. I think the field names alone would probably make airport security monitors shrudder. Think you'll ever see that on Freshmeat? ;-)

Tracy and I tried out our new grill tonight and it works great. Needless to say, I was reading the cooking tips as I was cooking, so I did it entirely wrong, but since burgers and hot dogs are pretty hard to screw up, it all went well. Turns out we got the wrong grill cover, though (it's too small) -- I'll have to exchange that next week.

I promised Janna a good meal cooked off the grill next weekend for letting us use their 4runner to bring the grill from my local True Value hardware store (of course) to our home.

A helpful LAM user (Chris at Advanced Data Solutions -- they do oil field simulations and whatnot) have been encountering failures on his system. He sent some test code, but I still haven't been able to duplication his problems. Hmm.

We've just changed the LAM model for handling signals in user code
-- LAM used to install signal handlers for SIGSEGV and the like during MPI_INIT. Now we don't install any (except for SIGUSR2, which we need for IPC kinds of things); the lamd just notices that the child process died due to a signal from the exit status and sends that back to mpirun. mpirun prints out a pretty error message and then kills the entire parallel app (this used to be done from the signal handler in the user code itself, which was usually reliable, but there were some problematic cases where it would go haywire). The code in mpirun has been bullet-proofed to make it much more robust, too. Unfortunately, we forgot to take into account MPI_COMM_SPAWN and friends -- this new plan doesn't take this into account at all.

The problem here is that there is no mpirun waiting to receive status/death messages when a child process dies (RTF_WAIT is not set for MPI_COMM_SPAWN processes). Hence, if a child encounters a signal, no one will kill the rest of the parallel app. Hrmm.

The easiest solution would seem to turn the signal-handling code back on in MPI_INIT (it's still there -- we left it there for backwards compatibility, you can manually activate it with the "-sigs" option to mpirun) for spawned programs. This is somewhat inconsistent with mpirun'ed programs, but will users notice?

A better solution would seem to have an mpirund pseudo-daemon in the lamd that can "emulate" mpirun in the lamd, just for these kinds of purposes. Heck, mpirun itself can utilize it so that the interface is the same everywhere. I certainly won't have time to get to this until I finish my dissertation, though...

I got notice that DFAS has deposited the first of four back payments into my checking account. It's the reimbursements for hotel and rental car for one of the two AT's that I did in Atlanta. While it's really just a reimbursement, it feels like free money. Must resist urge to spend it on house stuff...


I just noticed an annoying bug in jjc -- it evaluates underscores (i.e., emphasized HTML) before functions. So if you use the HREF function and have a URL with an underscore, jjc will changed that into <em>, and complain that there's no ending tag. Grr... gotta change that order of evaluation...

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


This page contains a single entry from the blog posted on April 21, 2001 10:20 AM.

The previous post in this blog was Gazizza, Bill.

The next post in this blog is I had a big history exam the next day and the only copy of the Fedaralist Papers that I had was *abridged*!.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.34