Advent Of Code

Over the past couple days, I've tried to solve some of the puzzles on adventofcode.com. I'm using this as an excuse to learn more about the Julia Programming Language. I already have played with it a little. Implementing a parser for legacy AIDA files was fun (and useful).
https://github.com/jstrube/AIDA.jl
I also like that you can use Julia in interactive notebooks a la IPython. I've played with this a bit (mostly for my own education. I'm happy to learn about mistakes, though).
http://nbviewer.ipython.org/gist/jstrube/c8aaeab300b9f52e9fff

To get really serious with a new tool, however, there's nothing better than exercises. I like how easy it was to use Julia to solve the problems over on adventofcode. (Not that the puzzles themselves were easy. I still haven't solved all of them.) Anyway, I've put my solutions on https://github.com/jstrube/adventofcode, mostly for my own reference, because the problems I solve on a daily basis are quite different in nature. If you're into programing puzzles, you're welcome to take a look.
I'm confident I'll get a lot of use out of Julia over the next couple years.

Plans for the New Year

Just in time for Christmas, I received approval for posting a job ad (also on inspirehep jobs). I look forward to starting my own research at PNNL in earnest. So, to set the context, here's a bit of a rundown of what we're trying to do in the near future:
The ILC detectors are preparing to start TDR in the next year or two. For this we need to answer a couple of difficult questions convincingly. We'll have to justify the choices for all of the detector parameters. We haven't really changed them since the LOI in 2009. That was before the discovery of the Higgs boson. We'll need to take a good look at them again and study if they are still optimal and how much small changes affect the physics reach of the experiment. For this, we need to build new tools to better understand the connection between the detector parameters and the measurement precision. In a PFA detector, the reconstruction is a big part of the detector concept. I'm interested in studying the performance of the reconstruction under both physical and computational aspects.
In no particular order, here are a few things we already know that need work.

• Vertex reconstruction and flavor tagging:
• How does it perform with more background?
• Is the innermost layer at the right distance from the IP?
• What changes are needed to implement gaseous cooling?
• Silicon tracking
• What are the current limitations of the tracking, and can we overcome it with a pixel tracker?
• What can be gained from a different aspect ratio?
• Calorimetry
• How big of an advantage does digital calorimetry have over analog?
• What's the right size for the readout?

I'm sure there will be other questions that come up during the year. I look forward to working on these and other items with a motivated and capable scientist who will join us at PNNL. Let's roll up our sleeves.

Devtodo2

Quick shout out to a nice terminal todo list. http://swapoff.org/devtodo.html

Even more useful with this bash function. Just put it in your ~/.bashrc.

alias todo="/path/to/devtodo2"
function workspace_cd() {
    cd $@ && [ -f ".todo2" ] && todo
}

alias cd="workspace_cd"

Now, every time I cd into a directory with a .todo2 file, I get a reminder of the todo items in that dir.

Subversion to github

A big part of the daily routine of a particle physicist is writing code. Unfortunately, we're not particularly well trained for this, so new developments trickle through the system rather slowly. Recently a couple of colleagues and I chose to re-start development of a package that had seen only little activity in a while. The code was hosted on subversion, together with dozens of other packages. For our project, we chose to migrate to github.

So here's a little review on how we got on:

1. create github dir
2. checkout old code from svn
3. check new code into git
4. commit code
5. start applying some patches and start coding

At this point a colleague suggested that we should preserve the old commit history from subversion when importing the code. Terrific idea! But we already started coding... I'm lazy, so starting all over is clearly not an option. So here's what I did.

1. Import the code from subversion into github including the commit history and existing svn branches and tags
2. checkout the repository with our developments
3. git log #gives you the history, together with the sha for each commit
4. git format-patch -4 HEAD # to get patches for the last 4 commits. This creates 4 patch files
5. git checkout <new repo from github import>
6. cd <new repo from github import>
7. apply the patches from step 4 one by one. I think the "git am" command would do all of this in one step, so that may be a better solution. I will try that next time.

At one point, there was a conflict in the merge. I have simply copied the conflicting file over from the other repo. Again, "git am" looks like it would have worked better. I'm still on the upward path of the learning curve.