Monday, 26 March 2012

Make MNRAS submissions look more like MNRAS

Have you ever submitted an article to Monthly Notices of the Royal Astronomical Society (MNRAS)? If not, I offer you this lousy joke,
Q: Who was the first electricity detective?
A: Sherlock Ohms.
and invite you to stop reading now. The rest of this post is irrelevant to you. 

If your answer was "yes", then you've probably noticed that just putting your article into mn2e.cls doesn't make it look quite like the final publication. If you care enough about such things, read on for a few steps that make a submission look more (but not exactly) like the final product. In short, you can change the font, fix the bibliography and stick to MNRAS style on some minor points.

Fix the font


I would love to know exactly what font MNRAS uses. The closest approximation I've found among the LaTeX defaults is Times. So the first step to improving your article's MNRAS-ness is to simply add

\usepackage{times}

to the preamble. To illustrate the difference, here's a comparison between the default font, Times and whatever MNRAS uses, all at the default font size.

Times is definitely an improvement.

Fix the bibliography

The first fix in the bibliography is to change its size. MNRAS sets the bibliography in smaller type than the main text but the mn2e.cls file doesn't emulate this. To fix things, enclose the bibliography in a \footnotesize block. That is, call the bibliography with something like

\footnotesize{
  \bibliographystyle{mn2e}
  \bibliography{paper}
}

If you use BibTeX and copy entries from NASA ADS, then you might find yourself being asked for more bibliographic information when your paper is being readied for print. Part of the problem is that the BibTeX entries are not always complete. For example, I often find that books and conference proceedings don't include the publishers' names and addresses. You can usually find these in the "default format" entry on ADS and enter them manually. For the appropriate entry names in the bibliography file, look in the LaTeX Wikibook.

The MNRAS bibliography breaks down on long author lists. There are several fixes for this. One is to modify the .bbl file after BibTeX runs and thereafter summon the bibliography with

\footnotesize{
  \input{paper.bbl}
}

so that it isn't recompiled each time. The other option is to use (or make) a different .bst file. Michael Williams has done such a thing and you can download his variant of mn2e.bst here. His variant doesn't work perfectly with the MNRAS directive of listing all three authors on the first citation and as "et al." thereafter. You get output like "Jones, Smith, & White (2012)", which is ugly. I've tried my own hand a custom MNRAS bibliography style to fix all this. You're welcome to download it here, give it a try and send me feedback. If you've worked out your own happy medium between the original MNRAS file and Michael's fix, let me know below.

Fix minor things

For whatever reason, mn2e.cls doesn't appear to flush equations to the left like in the journal. This is fixed by calling the class file with the fleqn option, as in

\documentclass[fleqn]{mn2e}

plus whatever other options you use. I thought this was a result of an outdated mn2e.cls but I'm clearly not the only one.

Finally, there is a host of small things that you shouldn't forget. I've either made these mistakes myself or seen them in arXiv submissions. Hopefully a handy list of common errors will help someone not make the same errors.

  • The article title is set in sentence case.
  • The running header is limited to 45 characters. If the title is longer, you must provide a short one.
  • Names of software packages are set in small caps. i.e. \textsc{code} in LaTeX. I sometimes see folks use other fonts. e.g. \texttt
  • Tables never have double lines.
  • Subreferencing is never done inline. That is, MNRAS won't allow "Cox & Giuli (1968, §27.3)". I don't think they allow page numbers either, even though I think they're useful...
  • No citations in the abstract.
  • "per cent", never %.

Further fixes?

Your submission should now look more like MNRAS but it isn't there yet. If you know how to fix this or anything other outstanding discrepancies, let me know in the comments.

Wednesday, 7 March 2012

Astronomical Software Wants To Be Free

From two articles on the reborn Astrophysics Source Code Library, which are themselves worth reading, I found myself reading a fairly bold arXiv submission from 2009 entitled Astronomical Software Wants To Be Free: A Manifesto. The initial summary cuts to the chase.

We advocate that: (1) the astronomical community consider software as an integral and fundable part of facility construction and science programs; (2) that software release be considered as integral to the open and reproducible scientific process as are publication and data release; (3) that we adopt technologies and repositories for releasing and collaboration on software that have worked for open-source software; (4) that we seek structural incentives to make the release of software and related publications easier for scientist-authors; (5) that we consider new ways of funding the development of grass-roots software; (6) and that we rethink our values to acknowledge that astronomical software development is not just a technical endeavor, but a fundamental part of our scientific practice.
All these points are expanded somewhat in the conclusions. Paraphrasing only the lead sentence of each point, the authors write eight suggestions for moving forward.
  1. We should create an open central repository location at which authors can release software and documentation.
  2. Software release should be an integral and funded part of astronomical projects.
  3. Software release should become an integral part of the publication process.
  4. The barriers to publication of methods and descriptive papers should be lower.
  5. Astronomical programming, statistics and data analysis should be an integral part of the curriculum for undergrad and grad students.
  6. We should encourage interdisciplinary cooperation with like-minded and algorithmically sophisticated members of the computer science community.
  7. We should create more opportunities to fund grass-roots software projects of use to the wider community. 
  8. We should develop institutional support for science programs that attract and support talented scientists who generate software for public release.
Do you agree? Do you adopting these recommendations would help to improve astronomical (or generally scientific) software?

In my own humble opinion, the real hurdles are release and documentation. If you can find a code, good luck installing it, learning how it works or finding out how the code is structured. But these are hurdles because it still isn't in a scientist's interest to do commit time to what are ultimately support tasks. So I think the most important point, of the eight above, is 2: software development should be fundable and funded. There are big gains to be made with solid attempts to get some real software engineering into scientific problems and it costs a lot less than building a telescope.

Thursday, 1 March 2012

Mount a remote filesystem locally with sshfs

I only occasionally need or choose to work from home. When I do, I need to get at my files on the department filesystem. There are many ways to skin this particular cat but a recent blog post by Matt Might mentions one of the easiest ways yet: a small application called sshfs.

The name says it all. This command line program mounts a remote filesystem at a local point over SSH. Usage is simple too. Just enter

sshfs user@host:/remote-folder/ local-mount-point/

and you can start using the files. I now mount my departmental home folder on my laptop and start edit my remote thesis as if it were a local file. To unmount, enter

fusermount -u local-mount-point

I use Linux both in the office and on my personal machines but the Matt Might's blog post mentions how to do it on other systems. It should be easy on Mac OS X because it's so Linux-like under the hood already. You also may have to install sshfs in some Linux distributions. I had to install it on Ubuntu 11.04 but it's as easy as

sudo apt-get install sshfs

which Ubuntu tells you anyway if you don't have sshfs installed.

Have you used sshfs for remote working? Problems to watch out for? Better choices? Let me know below.