A Physicist’s Travels

Being a particle physicist requires a lot of travel. In general, being a scientist means going to conferences, visiting other institutions, and collaborating with a global network of colleagues. The tools of particle physics tend to be consolidated at single locations, rather than at one’s home institution. As a result, particle physicists do a lot of commuting and telecommuting. Since the latter is still catching up with the quality of the former, we drive and fly all over the place.

For a long time, I’ve wanted to put a big Mercator projection of the globe on a wall and stick pins in it. Each pin would indicate a place I have been in my life (for more than just 1 day – I’ve been to plenty of airports just to connect). It would give me a sense of just how much running around I’ve been doing, largely in the name of science. The only reason I saw Wisconsin was because I wanted to pursue a Ph.D. in physics. I went to California not for the dot-com explosion but for the mini big bang being created at the PEP-II collider at SLAC. I went to Texas to be an instructor and a researcher. I went to Montreal to give a seminar. I went to Uppsala in Sweden to participate in a workshop on an electrically charged Higgs boson.

What brought me to Missoula, or Grand Island, or Ely? Each pin is a story, if not a collection of them. Think of the tales you can tell the person who looks at your map.

I owe a lot of my exposure to the world to physics. I expect a great deal more I as continue to grow in this field. Meanwhile, I’ll share with you my little life map – my digital Mercator projection with push-pins.


View Life Map in a larger map

Nominations for SLUO Executive Committee

Interested in representing and serving SLAC users? SLUO Executive Committee needs YOU!
Interested in representing and serving SLAC users? SLUO Executive Committee needs YOU!

Each year, the SLAC Users Organization (SLUO) hosts its annual meeting for users. For as long as I’ve been involved, the meeting is themed. This year, the theme of the meeting is SLAC science, from the depths to the heavens. SLAC users now represent research programs located deep underground, developing and using new accelerators here on the surface of the Earth, and looking far out into the cosmos. SLUO needs to have representation and participation in all of these exciting programs, and the annual meeting will highlight this.

The meeting will happen all day, next Thursday (Sep. 17). During the lunch, institutional representatives will meet with current executive committee members and nominate candidates for the next election cycle. Elections for the SLUO executive committee will be held this fall. SLUO needs your nominations! Talk to your institutional representative (group leader, principal investigator, senior researcher, etc.) and make sure they make nominations at this meeting!

Nominations can be made in person over lunch or on the web,

http://www-group.slac.stanford.edu/sluo/2009AnnualMeeting/lunchSignUp.asp

If you have an interest in serving users, representing them to the SLAC management, and acting on behalf of them (e.g. through science advocacy in Washington D.C.), SLUO needs you! Make sure you let your institutional rep. know you want to be nominated. If you know someone who is perfect for this, nominate them to your rep.

If you have a SLAC unix account, use SLAC equipment, work at SLAC, etc. you qualify to be a SLAC user! Make sure you’re registered – your vote is important, so make sure you can cast it.

SLAC is, more and more, a diverse community. From science projects located deep underground, to projects orbiting the earth and looking at ancient light from distant cosmic cataclysms, SLAC’s users are working to understand the total universe. Make sure your voice is heard; make sure your interests are represented.

Electronic Notebook Revisit: TiddlyWiki, meet Git

This past week, I got my SMU-provided desktop PC. The first thing I did was to install VirtualBox and then install a virtual Ubuntu 9.04 system inside VirtualBox. The default desktop installation was Scientific Linux 5. While this is an excellent platform for research, it’s terrible for the  desktop. This machine will be my primary means of desktop work – writing, graphical editing, handling documents. SL5 sucks for this work. Ubuntu rules.

As soon as I got the system setup, I realized I wanted a way to edit my electronic logbook seamlessly between my laptop, the desktop, and any other machine. A while back, I mentioned a few e-logbook models I had tried [1]. I settled on TiddlyWiki for several reasons. It has journal entry built right into it. It allows new “tiddlers” to be created and linked to journal entries; for instance, a tiddler about a specific to-do item. It’s also a plain-text HTML file incorporating javascript code, which means it can be hand-edited and (more importantly) managed using something like CVS.

The challenge with TiddlyWiki is that I can’t find a reliable way to host the wiki through a central server. Doing so would allow me to edit the wiki from any machine with a web browser, asynchronously. There are external websites that will host your wiki, but the point of a logbook is to have it under my control. I decided instead to manage the logbook with Git.

Git is a software collaboration system used to manage the Linux Kernel. It feels similar to CVS, but is supposed to provide much better control over patching, branching, and other collaborative software development needs. I chose it because (a) I have never used it before and (b) if it’s good enough for Linus Torvalds, it’s good enough for me.

I copied my existing logbook directory (Notebooks/) to my home server. I then initialized the directory tree as a git repository (“git init”). I then added all existing files to the repository (“git add .”, followed by “git commit”). Now I had a central copy of the logbook capable of being pushed out to my laptop or desktop.

Let me pause to discuss how I structure and manage my logbook. I have a top-level directory called “Notebooks/”. I decided to keep one logbook for all my projects, rather than one per project. I can then tag tiddler journal entries with names like “babar” or “atlas” to know whether they are relevant to different projects, and search by tag. This was better than having lots of directories.

I did choose to keep one separate logbook per year. This is similar to what I did when I kept a paper logbook. I have a subdirectory called “Notebooks/2009”. I then had to make one more decision: how to handle media. I decided to keep subdirectories that are “MONTH/DAY” for media. For instance, if I need to put an image of a chart in my logbook on 09/01, I make the subdirectory “Notebooks/2009/09/01/” and put the image there. I then link to it in my  TiddlyWiki, and the image appears in my logbook. This may be hyper-organizational, but it allows two things. First, it relieves me of the conflict of similarly named files. If I have two graphs from the same source, one a revision of the previous, then I don’t have to name them differently (assuming the change happens over longer than a day). Second, it lets me associate date with result, and I can really think back by time index in my head to find something.

Finally, I like to have my default TiddlyWiki view (the “DefaultTiddlers” tiddler) be “[tag[journal]] [sort[-created]]”. This puts the journal entries on the inital load of the logbook, in order of date  from newest to oldest. This is more like a real logbook. When you open it, the most recent entries are closest to where the current entry is added.

Back to Git. Now, I can create the Git repository on my desktop or laptop for the Notebooks and pull the central copy to the desktop machine. I can then edit and push changes back to the server, to be picked up by my laptop. So far, I find this more than sufficient for my editing needs. We’ll see how this goes when I am on the road.

This is my current model of managing a logbook. I’m a pragmatist at heart. If this is clunky or cumbersome in the future, I’ll find a new model.

Useful links:

TiddlyWiki homepage
Git Homepage
Everyday Git Commands

[1] http://steve.cooleysekula.net/goingupalleys/2009/03/26/electronic-logbooks/