Frigid Digit

Georgia Tech Sailing Club hosted its intra-club regatta on Saturday. Four 420s sailed out into Lake Lanier and completed a few races. It was very informal, and the light winds made things maddeningly slow at times, although things were never so calm as to prevent deliberate maneuvering.

I didn't win any of the races, but my crew and I came in second place a few times [which doesn't technically matter - sailing rewards winners only]. There are subtle tactical and strategic differences that distinguish experts that I began to pick up on. A strong start is key to dominating a pack of boats - you receive "puffs" of stronger winds earlier and can speed up to stronger positions. Additionally, good positioning and tacking strategies tend to grant a smart skipper right of way during those moments when two boats come upon each other.

There were some tactical matters as well. One boat just seemed to "go faster" in identical wind conditions. Since this regatta consisted of boats of the same class and make, presumably the fastest were those trimmed the best. After we stopped racing, I requested the experienced crews to sail a straight course up wind so that I could follow along and trim sails and crew locations to improve my speed relative to them. That helped considerably to identify the optimal sail positions.

Ralph's Picassa gallery of the day.

Here I am sailing downwind. This is the boring part of the race.

Image

The Nacra catameran that capsized after flying one of its hulls:

Image

Update

While getting my haircut today, I thought about what it might take to determine the optimal strategy for a particular boat under a given set of wind conditions in a regatta. Simplifying assumptions would be:

• uniform wind direction and speed across the entire area


• no other boats to create local calm areas with bad air or force suboptimal maneuvering


• uniform sea state


• ideal sail and boat trim

This hypothetical systematic approach would attempt to minimize total time around a pair of marks. Specifically, this would determine:

• what course to make that minimizes time to reach the upwind mark


• which tack to start on


• when to tack


• whether to "run" or "broad reach" during the downwind leg

Since being at the right place at the right time with the wind on the starboard side is advantageous when encountering other boats, the model might favor a starboard tack at certain points in the course.

It seems like this could be computed given

• an accurate speed model of the Club 420 under typical loading conditions for each point of sail


• performance model of a well-executed tack


• performance model of a well-executed gybe

This would attack the problem that, I suppose, gets answered through intuition and experience by 'good' skippers. Of course, it completely ignores the influence of other boats whose presence could easily compromise a good single-boat strategy. It also assumes the skipper and crew are good enough to maneuver in ways that satisfy the performance models; this depends on training and skill. Nevertheless, it seems like having a good theory here would be a great way to quickly gain a practical intuition that could be deployed out on the water.

Someone get me a performance model!

Git solves your problems

So last night, I wanted to install a Subversion server on Emma's darling quad-core behemoth hosting akerr.net among *other things*. Inspecting the installation, it seems mod_dav was not compiled into Apache2.x, and no one after Apache 1.3 seems to suggest loading it as a dynamic shared library. I successfully compiled several test builds of Apache2.2 in user space, but matching Emma's configuration in a maintainable way would have been a nightmare inside of doubtfulness wrapped in the promise of sleepless nights down the road if things go wrong.

Then I went looking for alternatives. It seems the only administrative prerequisites for hosting a remote Git repository are that the host runs sshd and you to have an account on said machine. After installing the lovely msysgit git client for Windows on my home desktop, I performed the following.

On the remote side:

$ ssh akerr@akerr.net:
$ mkdir akerr.git && cd akerr.git
$ git --bare init
Initialized empty Git repository in /home/akerr/akerr.git/
$


On the local side:

$ cd C:/research/akerr
$ git init
$ git remote origin "ssh://akerr@akerr.net:<ssh port>/~/akerr.git"
$ git add infrastructure/
...
$ git commit -a -m "initial revision of libkerr"
$ git push origin master
...
$


This is all that is needed. To pull from the remote host, simply perform the following:


$ git pull origin master
...
$


The elegant components of this solution are:
- doesn't require superuser access or configuration changes on the host
- security is a function of SSH
- git is fast and functional in an isolated environment

Thank you, Emma, for the free hosting. This helps you too. : )

Wheel of Reincarnation

I read an interesting paper describing the Wheel of Reincarnation - the phenomenon in which certain specialized computations are handled by coprocessors but then these computations are shifted back to the main processor as CPUs gain in performance.

General computing power, whatever its purpose, should come from the central resources of the system. If these resources should prove inadequate, then it is the system, not the display, that needs more computing power.

[Myer and Sutherland. "On the design of display processors"]

I guess this phenomenon is satisfied by general-purpose computing on GPUs that brings the graphics processor back into the 'system' instead of being a specialized co-processor for accelerating DirectX.

With GPU Ocelot, the system is getting more power.

Emma's Birthday!

Let us also observe that my darling Emma is twenty six years awesome as of yesterday. We celebrated with supper, exquisite company, Maker's Mark, and cookie cake. Presumably, celebratory ice skating is upcoming.

Happy birthday, Emma!

Atlanta Calling

By now, you're surely tired of seeing the evidence of my awesome summer. To keep you interested in lieu of a complete blog post chronicling my travels to HPEC'09 and then IISWC, here is a Google Image Search that should elicit a chuckle among some of you.

Example:



Real post coming soon.

Post Summer 2009

I am back from Seattle. Here is a taste of what I did this summer. Special thanks go to all of the people I met along the way.

Flying a Cessna 172S:

link

Sailing on Lake Union:

link

Bike ride to Lake Washington:

link

Helicopter flight over Seattle:

link

10,000 ft climb of Mt. Rainier:


Things I want to accomplish personally this Fall:

* nail down research agenda working toward thesis
* paper at PACT
* sail considerably, taking you and others with me
* bicycle over a notable distance
* hike somewhere notable
* undertake a slaying expedition
* gain upper body strength for rock climbing options class next Spring

Let's see if a more productive Andykerr can accomplish all of this. I'll have to put considerably less whiskey in my coffee the next few mornings.

VSIPL Design Thoughts

As an implementer of the VSIPL API, I've thought of several small criticisms of the library. By posting them here, Google will record them for posterity.

* VSIPL Core Lite should require implementations to include vsip_complete() -
This could easily be a no-op on any implementation that doesn't perform some sort of lazy evaluation. Applications could call it without fear that things may break if they move to another implementation.

* VSIPL API should include vsip_usermalloc() -
This would allocate user-accessible data blocks in a manner that could be used efficiently by the library. The alternative is let the user perform its own memory allocation; this has no regard to alignment or pinned paging.

* VSIPL should include more robust error reporting methods -
Reports might be implementation-dependent, but it would enable much better robust composition.

I am confident none of these requirements would break existing implementations or negatively impact users.