Sunday, July 26, 2009

I kinda get Python. Kinda.

Phew, long week and long weekend. I had my weekend WTF moment when I caved to my daughter's pleas for tonic water. I figured that there was no way a 19-month year old would have more than one sip. She proved me wrong, downing all that I gave her. There's nothing quite like watching a toddler wander around with a rock glass full of tonic. That should be on a Hallmark card or something.

Anyway, I've been slllooowwwwllly progressing with Python and MatPlotLib. There are some concepts that are still beyond me.

I've continued to play with the Weasel program; it's interesting enough to keep me programming while giving me plenty of output to visualise. I've always wanted to see how changing the number of offspring per generation AND the mutation rate would affect the number of iterations needed to finish. This requires a lot of runs- not only do you need to simulate many mutation-rate & number-of-offspring combinations, you also need to perform many simulations for each combination to get an average number of total iterations (because it's random, the results can differ quite a bit.)

This plot shows the variability in similar runs (and shows that I can do whisker plots now.) The Y-axis is number of iterations (LOG SCALE!) to completion, the x-axis is number of offspring set for the simulation. Each point represents the average of 100 simulations using the same inputs; the whiskers show the standard deviation. As the number of offspring increases, both the standard deviation and number of iterations decreases. This makes sense- with more offspring, you have a greater chance of a "good" mutation. The log scale makes the change look small, but it's order magnitudes!

I repeated this, but now I varied both mutation rate AND number of offspring. With 10,721 combinations, I lowered the number of runs per combination to 30 from 100. This left me with 321,630 weasel runs (two days of calculations!) This contour plot shows the variation in average number of iterations to completion when the two controls are changed. Note again a log scale, and also note that I had a very, very hard time setting up a proper log scale color bar. The bar goes from the low 10's to the high 400's.

What is interesting here is that if you follow the contours closely, you see a rebound in the number of iterations required as the mutation rate goes up high enough. This means that for a given number of offspring, there is an optimal mutation rate for the fastest convergence: too low and the process drags on forever, too high and we cannot converge because there is so much variation. Although I expected this result, it was still neat to see visualised like this.

The big personal accomplishment here was building these results - from the weasel runs, the scripting, all the way to the plotting - in Python. I would like to start using this language for work, but I don't want to waste research time learning an extra language.

Saturday, July 25, 2009

Black Mesa

On the drive from Santa Fe to Los Alamos, one passes Black Mesa, a large volcanic outcropping located in the San Ildefonso pueblo. The mesa stands out because of its distance from the other mesas on the Jemez plateau as well as its black and green appearance.

My wife took some neat pictures of the mesa on the way to Espanola:

Wednesday, July 22, 2009

Yeah. What he said.

"Science knows it doesn't know everything or else it would stop." Words of truth and wisdom. And hilariousness.

Shamelessly stolen from Pharyngula.


I've taken a short vacation, hence the lag in posts lately. However, I do have plenty to talk about.

The first item is the arrival of my Galileoscope last Friday!

Some assembly required, eh? Wasn't too bad, however, and soon I was spying on the neighbors looking at the night sky.

Unfortunately, the moon hasn't been out early enough to test the 'scope yet. Being a cheap instrument on a cheaper tripod, I had a lot of trouble getting stars into focus as well. Additionally, this is my first telescope, so I'm still learning how to use it properly. At this point, I'm waiting for the next night where I can get a good, clear shot at the moon. This will make for a much easier time getting objects in focus.

Thursday, July 9, 2009

Webcam, part 1

After moving to Los Alamos, I started playing with my webcam on my Linux machine. I ran into an aptly named command-line-interface package, "webcam", through Ubuntu's package manager and immediately started experiementing. The view outside of our office window is beautiful, but much more stunning in time-lapse:

When I tried to launch the program from the crontab, I recorded some great sunrises, but the process died at 11:45 consistently. This really sucks considering the footage of the snowstorm and the following melting I partly captured.

I'm working on expanding this into a year-long project.

Wednesday, July 8, 2009

Methinks it is like a Python

On Monday, my second book on Python programming arrived in the mail. My first, Learning Python (O'Reilly), is well written but slow- I learn best by plowing through some examples and then filling in the gory details. Learning Python works in the opposite direction, so I grabbed Python Scripting for Computational Science (Springer). This book has been great for getting up to speed post-haste.

Now that I've had some free time, I've spent the past two evenings playing with the Python language and was able to recreate Richard Dawkin's "Weasel" program. This program takes a target phrase, "Methinks it is like a weasel" (Shakespeare, anyone?), and a random group of letters of the same length. Over each iteration, an offspring of the jumbled phrase is created by randomly changing some of the letters. Of X offspring, the one nearest the target phrase (the "fittest") is chosen and another generation is made. Eventually, and rather quickly, you achieve the target phrase through a set of random mutations guided by a judgment of fitness -- a neat demonstration of the principles of evolution.

Although I was able to create this program quickly using Perl, I thought it would be an excellent Python exercise. I was able to hack together a version pretty quickly, but given the powerful matplotlib package, was able to go a step further and visualize some of the results.

Convergence to the target phrase in 8332 iterations. Each generation produced 10 children phrases; each letter for each child phrase had a 0.1% chance of mutation.

Not too shabby for a few hours work. Compared to my Perl version, the source code is shorter but feels much less elegant. They both run very quickly. Python gets points for the ease of visualization through matplotlib; Perl gets points for easily integrating into a CGI script for web browser interface (though Python supposedly does this equally as well.) The comparisons won't be fair until I've given Python more than a few days' worth of work.

Here's a good online version of Weasel.
Here's another.

Tuesday, July 7, 2009

More Hail Pics

A few colleagues took some great pictures of the hail and the resulting damage. Check it out. Beyond the dents and punctured plastic, a few people I've talked to have had windshields cracked as well. My wife, along with taking some nice pictures herself, was sharp enough to keep the car under a tree, sparing the poor ol' Focus from the wrath of the ice chunks.

Sundays are for Hikers

After a long hiatus, I returned to my Sunday hikes this past weekend. It was the first time I was out since May, and things are much greener now.
At the bottom of the canyons:

At the top of the mesas:

Additionally, while at the GEM conference in Snowmass, CO, I was able to sneak away for a quick hike. We rode the ski lifts up the mountain then walked down:

Next week, I'll be going on some longer hikes again, so I'll return to the google-map format.


Yesterday, amid a teleconference, a torrential hail storm hit us pretty hard. It got to the point that I couldn't hear anything from the telecon over the noise of the hail rocking the sides of the building. Most of the hail was gumball sized, but at its worse, there were chunks that were larger than golf balls. Nearly every car outside was pelted until nicely textured with hundreds of divots.

Being at the lab when this happened, I was unable to take pictures of the mayhem. Fortunately, Awesome Wife was johnny-on-the-spot with the camera at home:

Although afternoon thunderstorms are common for Los Alamos at this time of year, yesterday's was unusually violent. At least it keeps things interesting.

Monday, July 6, 2009

Happy 4th.

I'm still waking up from a four-day weekend (thanks to the Lab's policy on national holidays). It was great- I did almost nothing. For example, on the fourth, I washed and waxed the car while catching up on podcasts, then roasted marshmallows in the back yard with the family. My daughter learned the joys of snap-pops (those cheap firecrackers that you throw to get them to pop), and that was it. Despite all of my promises, I still didn't update this blog at all. That was more or less on purpose. I was intent on doing almost nothing. After another fast-paced conference season, that's really what I wanted.

Again, almost nothing... Sundays are for hikers, y'know. Expect pictures up tonight.

Now, back to work.

Wednesday, July 1, 2009

So You Want To Model: Part 2

DISCLAIMER: The author, being a Michigan grad and a former member of the CSEM, is probably pretty biased today.

This post is the second of a two-part discussion resulting from a comment calling for (rather lightheartedly) open-source space environment computer modeling. Open source numerical modeling would be a first (and big) step in solving a classic problem in theoretical studies using computer codes: such codes are often held tightly to the chests of those who wrote them, leaving others wondering what is really happening under-the-hood. At the now-finished GEM conference, attendees could see this effect first hand: several different models were used to simulate the exact same conditions using the exact same theory (ideally), but the results were fantastically different. Without a true understanding of what is going on under the hood, such differences are irreconcilable.

In the previous post, I presented one potential solution: taking advantage of the CCMC to evaluate several models in the community. Today, I would like to highlight the work of the University of Michigan's CSEM group, who has worked to be as open as possible with their models. The efforts of this group, in my humble opinion, provide the most transparent set of numerical modeling tools.

CSEM's flagship code is the Space Weather Modeling Framework, a program that executes, synchronizes and couples several separate space environment codes together. While not truly open source, the SWMF (or, simply, the framework) has features that bring it close to the mark.
  • First, the source code is available for download after completing a license agreement. This download includes not only the SWMF, but most of the codes integrated into the framework already.
  • The framework and included codes are fully documented. This provides the space science community with a full description of under-the-hood aspects of the code while simultaneously helping new, non-CSEM related modelers use the framework.
  • The code is tested nightly on a variety of systems and compilers. This is not just for the benefit of the core CSEM users- it is an effort to proliferate the framework among interested parties. If it didn't work on your system with your favorite compilers, why would you use it?
While not truly open source, it's close. If you really wanted to see how the code is getting its results, you could easily do so. Although unlikley (for a variety of reasons), these are the types of steps that should be taken across the entire community.