Organizing references

Sort of on the opposite end of what I wrote about last week (on managing edits of my own papers), I recently came across a good way of managing citations and references.

Previously I’ve been compiling BibTex files by hand: I have a complicated scheme set-up with a central bib directory. Inside it is a master.bib file and a bunch of subdirectories. The subdirectories are categories: general relativity, PDE, differential geometry, etc. In each category are several smaller bibfiles. Each bibfile represent a subcategory, and the bibtex key I used are always of the form “[category]-[subcategory]-[authors' initial]-[year]“. By keeping separate bibfiles for separate subcategories, editing is easier. And I have a script that recompiles all the bib entries from the subcategory files and dump them into the master.bib file. Furthermore, the script also compiles the key-author-title information and dump them into a dictionary file, which I can then import in Vim to get quick citations. (I’m actually quite proud of this abuse of the vim dictionary that I am using.)

I’ve heard many good things about Zotero and Mendeley, and I have seen Zotero in action. While I really like its direct integration to firefox which allows it to very simply import citations from the web, I am not so thrilled about using a cloud service for managing my citations.

By way of Slashdot, I learned about Jabref. It is Java based and automatically platform agnostic (so I can use it both on my primary Linux computers and also on my Windows computer if I have to). I like its ability to group/tag articles making them easier to find, and its BibTex based backend (making exports simpler). Furthermore, one can link entries with stored PDF files. And with the database stored locally, syncing the bib file and the “link” is as simple as copying the entire directory.

Gradually I plan to migrate not just papers that I cite, but also papers that I read to the database. It provides a good, searchable interface for papers in general. Right now finding a paper on my harddrive involves invoking the unix command “find” and requires remembering either the lastname of one of the authors, or some keyword in the title in proper abbreviation. This contributed in part to my having two or three copies of the same papers on my harddrive. Jabref will certainly help.

I also like the fact that it has a Review field in the bib entry, so you can jot down some thoughts you (or other people) have about the paper.

Snowflakes

It took me two tries to get out of my flat this morning. I really ought to get into the habit of looking out the window in the morning; too often do I open the front door, ready myself to step out, only to turn back to fetch my umbrella. The annoying thing about snow is that I can’t hear it, unlike the pitter-patter of rain.

Somehow or another I ended up looking at Wilson Bentley’s micro-photographs of snow crystals. And a question forms in my mind, “Why are they all so symmetrical?” If all snowflakes were to look alike, then perhaps the dynamics leading to the formation of snow crystal is stable, and the global convergence unto a completely symmetrical pattern would not be surprising. But not all snowflakes look alike. In fact, colloquially we speak of them as each completely different from every other. This implies that the dynamics of snow crystal growth should be at least somewhat sensitive to atmospheric conditions in a local scale (and perhaps to the nucleus that seeds the crystal) so that the seemingly random to-and-fro dance as the snowflake falls from the sky can effect different shapes and branches.

Now, much experimental evidence has gone to show that the formation of ice crystals tends to by catalyzed by impurities. Pure water can be supercooled, in normal pressure conditions, to temperatures below 273 Kelvin. But in these situations a single mite of impurity dropped into the water can cause the entire beaker to freeze over suddenly. Similarly, ice crystals in the upper atmosphere tend to form around impurities: bacterium floating in the air, dust or ash, or perhaps particles introduced artificially. So one may surmise that the fact that all 6 branches of a snowflake grows in the same way because, somehow, the eventual shape of the snowflake is already encoded in the original formation of the central nucleus. Let me try to explain why this hypothesis is not very convincing. I’ll make one a priori assumption, that the growth of a crystal structure is purely local, and not due to some long-range interaction.

To draw an analogy, consider a large group of acrobats. They are trying to bring themselves into a formation around a leader. Disallowing long-range interaction can be thought of requiring that the leader cannot shout out orders to individual troupe members. But we can allow passing of information by short-range interactions, i.e. whispering instructions to the people already in formation. So the leader stands alone at the start. Then he grabs on a few people nearby to form the nucleus. Then he tells each of the people he grabbed a set of instructions on how to grab more people, where to put them, and what instructions to pass on to those people (included in these instructions are instructions to be passed on to the even more remote layer of acrobats and so on). Then if the instructions were passed correctly, a completely ordered pattern will form. But as anyone who has played the game of telephone can testify, in these scenarios some errors will always work its way into the instructions. In the physical case of snowflakes, these are thermodynamical fluctuations. So some irregularities should happen. Now, if the instructions the leaders were trying to pass down were very short and easy to remember, the errors tend not to build up, and the formation will, for the most part, be correct. But keeping the message short has the drawback that the total number of formations one can form is fewer. In the snowflake case, one can imagine somehow each small group of molecules in the snow crystal can encode some fixed amount of information. If the encoding is very redundant (so the total number of shapes is small), then the thermodynamical fluctuations will not be likely to break the symmetries between the arms. But considering the large number of possible shapes of snowflakes, such encoding of information should be taxed to the limit, and small fluctuation (errors in the game of telephone) should be able to lead one arm to look drastically different from the others. One possible way to get around this difficulty would be to use some sort of self similarity principle. But this will suggest the snowflakes are true fractals, which they are not.

The Kodama vector field and the gravitational red-shift

I was reading a survey article by Jaramillo and Gourgoulhon on mass and angular momentum when I come across the notion of the Kodama vector field. (Actually, I first heard of it from Mihalis Dafermos last summer; I’ve just completely forgotten about it until now.) I took notice of it because of a discussion yesterday in a seminar on the red/blue-shift effect. Since this post will focus mostly on the use of the Kodama vector field in analyzing gravitational red/blue-shift, I will start by an overview of the effect as well as some philosophical caveats.

Gravitational red/blue-shift
It is already well-known in folklore that a strong gravitational well causes light emitted to lengthen in wave-length. The standard, classical (not involving general relativity too heavily) explanation goes something like this: we know that the total energy is conserved in the motion of classical mechanics. We now take a hybrid quantum-mechanical/Newtonian-corpuscular view that light is carried by particles called photons, and that the intrinsic kinetic energy of the photon is , where is Planck’s constant, and is the angular frequency of the radiation. Suppose a photon is “produced” inside a gravitational well (say, near a very heavy star, or near a black hole). Its total energy will be . Now the photon escapes the gravitational well, to a point where the gravitational potential energy is higher. Then since total energy is conserved, the kinetic energy must correspondingly decrease. Looking back at the definition of the kinetic energy of a photon, this means a reduction in the frequency, which also means a increase in wavelength, since the product of frequency and wavelength is a fixed constant, the wave-speed, or the speed of light. This is why light escaping from the vicinity of a black hole will be said to be red-shifted. Analogously, a photon falling toward a black hole will gain energy and become blue-shifted.

Now we move toward general relativity. A problem immediately arises: there is no such thing as a preferred inertial frame. Whereas it makes sense in special relativity and in Galilean mechanics to compare two distant observers as “at rest with respect to each other”, the Principle of General Covariance makes the same comparison nonsensical in general relativity. Geometrically, this is the problem of having curvature: parallel transports of a vector is now path dependent, so there is no one unique way to define a “parallel vector” at a distant point B of some known vector here at point A. As is well-known, the frequency of light can also be shifted by the Doppler effect (in the acoustic sector, this is the effect where the siren of an approaching ambulance sounds higher pitched than that of an ambulance driving away). We will describe the geometric interpretation of this effect later. If there is no canonical way to pick an observer, there is also no way to say definitively what the frequency of light observed at a point is.

Mathematics and Jargon

Each profession has its own set of special language: some, like the medical profession, rely on long and precisely defined words, often with Latin, Greek, or German origins, to describe objects and events that we do not encounter on the everyday (I doubt anyone actually found the need to use pneumonoultramicroscopicsilicovolcanoconiosis in everyday conversation [it is a lung disease caused by inhalation of metallic dust]); some, like the legal profession, attach a preferred meaning to common everyday words (in addition to special terminology), and put certain heft on syntactical and grammatical specification to say exactly what they mean.

In the natural sciences, the tendency has been toward the coinage of words to refer to new objects or ideas. My guess is that this has to do with the earliest natural philosophers taking a cue from Adam and giving a name to everything they have not seen before. In mathematics (which, by the way, while may be arguably natural by certain definitions, is not a science), on the other hand, the tendency has been toward usurping everyday words for specialist purposes.

Managing papers with Subversion

Jumping through a link from Terry’s blog, I came across this article on the Secret Blogging Seminar describing how to use Subversion to keep track of one’s papers. (Better yet, this can also be implemented for collaboration.) This is one of those ideas that upon hearing, I slapped my forehead and went “why didn’t I think of it?”

In the past several months (after moving to my current position), I’ve just used rsync to download the files from the department server to my laptop before I start work, and to upload the changes afterward. This carries with it a slight headache: if I made some changes on the work computer, and if I bring my laptop to a coffeeshop with no wireless signals, I am in somewhat of a bind. I will have to edit my file, and be very careful that once I get internet access to merge the new version on my laptop against the version at work so all the changes are kept. With svn, I can look forward now to intelligent merging of the files automatically.

Subversion is what is known as a revision control system. It was developed in the land of computer science for manage computer code, especially across collaboration. The program makes it easy to keep track of revisions of a file: it knows which version is current and what changed between it and the previous versions. So instead of having to number each version of a file by hand and keeping track of the numbers, the computer does it for you. This reduces clutter in the workspace and minimizes the chance of mistakes. Furthermore, as we all know computer code tends to contain bugs (to err is human). With a system like this in place it is much easier to correct boneheaded mistakes: one just needs to revert to a previous version. The full documentation by the system of the changes made to the files also makes it easy to track down where and when a mistake happened.

A side benefit of subversion is that the files can be reliably merged across two separate working copies. This allows me to keep a central copy of my papers on the department server, and synchronize any changes between there, my laptop at home, and any other computer I may choose to use.

There are very many different ways of using subversion. Here I’m only going to describe the way I use it. (Just took about 20 minutes for me to read the relevant documentation and implement it.) Here I assume the user has

• A personal computer running linux, with svn-client software installed.
• Access (via ssh) to a server running linux/unix, with svn software installed.

Quick set-up instructions:

1. First we need to create a repository. A repository is a directory where all the version information will be held. Log into the server via ssh (or if you have local access, just log in). Let us just give the repository a generic name, say, “WorkSVN”. Issue
   

   svnadmin create ~/WorkSVN

   This will create the repository under your home directory.

2. Next we need to create a project. A project is a directory in which you hold a collection of files you want the svn system to keep track of. Suppose you already have a bunch of TeX files sitting in a directory called “PaperDrafts” under your home directory. We’ll just import the entire directory as your project
   

   svn import ~/PaperDrafts file:///[PATH TO HOME DIRECTORY]/WorkSVN/PaperDrafts

   Notice that inside the URL line, one cannot use the tilde-expansion for home directories. To find out the path to home directory, you can “cd” to the home directory, and issue

   pwd

   This should return a path like

   /home/XXYY

   Then the URL in the command above should be

   file:///home/XXYY/WorkSVN/PaperDrafts

3. If you want a local working copy of the files, you can now first remove the PaperDrafts, and “download” it from the svn server.
   

   mv PaperDrafts PaperDrafts.bkup
   svn co file:///home/XXYY/WorkSVN/PaperDrafts ~/PaperDrafts

   The first command moves your old copy out of the way. The second command downloads, from the subversion system, all the files in the project you just created. Now double check all the files are there! Then you can clean up the back up copy with

   rm -rf PaperDrafts.bkup

4. Now, to get a copy of the files on your laptop, we have to download it from svn. Suppose your server has a server name “Unseen.uni.am”. (This should be the same name you used to ssh.) Then just go to your computer, make sure you don’t already have a folder named PaperDrafts, and issue
   

   svn co svn+ssh://XXYY@Unseen.uni.am/home/XXYY/WorkSVN/PaperDrafts ~/PaperDrafts

   where the “XXYY” before the @ symbol is taken to mean the username you used to log into your server. The “/home/XXYY” after the server name is the path to your home directory on the server. Now after entering your password, you should have a copy of the papers!

To download the files to any other computer, just repeat the last step above.

Now, suppose you made some edits, what do you do? The principal commands to know are “add, del, copy, move, update, commit”.

• If a file is modified in place, then you don’t need to do anything special: svn already know to keep track of the file.
• del, copy, move: to remove, copy, or move/rename files inside the working directory, one needs to use the svn tools instead of the native linux tools. This is so that the svn system knows that the files are to be changed. So to remove a file, issue
  

  svn del [path to file]

  to copy a file,

  svn copy [path from] [path to]

  and similarly for move.

• If you create a new file or directory, you need to let svn know that this file/directory needs to be kept track of. So you issue
  

  svn add [path to file/directory]

• When you’ve done all the edits you want. You need to synchronize the local copy with the server. To do so just issue
  

  svn commit ~/PaperDrafts

  and any changes (deletions, copies/moves, new files, modified files) will be propagated to your server.

• If you now go to another computer onto which you’ve already downloaded the TeX files before and want to update it to reflect any changes you’ve made since, you can issue
  

  svn update ~/PaperDrafts

Lastly, for commits and adds and deletes, it is often prudent to use the “-m” flag to svn to add a comment about what is being done and why you are doing it. Just in case you will look at it later.

The usage described here is very simple and primitive. For more complex operations, read the documentation for Subversion. It is available on its website.