Publishing my thesis in book form

This is a story and guide to publishing my thesis in book form. If you’re looking for the good stuff, feel free to skip to the instructions.

Last year I completed my PhD studying interferometry for the detection of gravitational waves. My thesis is now available in electronic form that anyone that wishes to read it can obtain, and the source code is on GitHub. A paper copy – following the standard fabric-bound, A4 format specified by the university court – is available courtesy of the university library: at the time of writing, my thesis is stored in the research annexe on 29 Saracen Street (interestingly, that’s not on campus, but near the Bowmore whisky bottling plant in the north of Glasgow).

The title page of my thesis. Pretty, eh?

One of the ways in which I procrastinated while writing it was to try to produce diagrams, charts and figures which were entirely made from vector graphics such that they could be scaled for display or print at any resolution without losing fidelity. This was unfortunately due to rather of an obsession I have with data integrity: why throw away information when you don’t have to? It might come in handy later. Information is lost in photographs when they are scaled up – for example in preparation for print. This is in general true of all raster graphics like the JPEGs, PNGs and GIFs used all over the web and in designs for print. Vector graphics typically look nicer when displayed in a PDF viewer at high screen resolution or printed with a high quality printer. There are downsides, and there is definitely an appropriate time and place for raster graphics, but not for most of the plots and diagrams in my thesis.

The upshot of all of this time spent making nice, scalable graphics was that it was possible to render the thesis in (theoretically) infinite fidelity for printing. My printed thesis graphics looked really nice in the A4 tome I submitted to the library, but the book design itself looked dated and boring. That’s what gave me the idea to investigate professional print services.

University of Glasgow approved book binding service from Downie Allison Downie in Partick, Glasgow. While the workmanship is good, the university-enforced standard design is boring. No thanks!

Publishing my book

My thesis is almost entirely made up of text, plots of data and diagrams. Almost all of the diagrams are vector graphics. The scant few raster graphics were of circuit board layouts (which could, in hindsight, also have been produced in vector format). I had no photographs, both because my work was mainly focused around simulations and designs for new, not-yet-built experiments, and because of my aforementioned dislike for raster graphics.

As I had written the thesis in LaTeX – a scripting language for documents – I realised it would be straightforward to resize my A4-formatted thesis into a nicer A5 size more suited for reading, and in the process lay it out the way I really wanted to instead of conforming to the boring old University of Glasgow approved format. If nothing else, I’d save on paper by decreasing the margins and text spacing to result in a book more like the ones you buy today. Don’t you hate it when you have to turn the page so frequently?

So, what follows below is a guide to how I published my thesis as a nice, custom book.

Step 0: find an online book printer

The obvious preliminary step. After a bit of searching I found InkyLittleFingers, who had good reviews, made everything at their own factory (in Gloucester) and offered what seemed like a pretty comprehensive binding service that could be arranged completely online. Importantly, they are based in the UK, which cuts the cost of postage, allows for efficient communication regarding specifications, and provides a VAT exemption due the rules in the UK regarding book tax.

One of the appealing parts of InkyLittleFingers’ offer was the level of passive support they provide in the form of guides on their website. They even have a YouTube channel with some video tutorials.

There is a comprehensive guide to designing the artwork for the book. “Artwork”, as I learned from their helpful glossary (under “Useful terms” on this page), is the term in the book binding industry for the content you want printed. That means both the case (i.e. the front and back covers and the spine) and the book block (the inside pages) – the whole thing.

Form on Inky’s website for creating hardback book orders.

The website is a little rough around the edges, and sometimes you might find yourself hitting a 404 or some other sort of error, but for the most part it works as intended. To order a book you first need to upload your artwork and ask for an automatic quote. As I wanted a hardback, I went to this quote form and filled in the details. You can guess the page count just to get a quote, but you need to know the exact page count before making a proper order. The page thickness you choose is combined with the number of pages you specify to calculate the spine thickness, which you then have to use to appropriately dimension your cover design. After some research of their FAQs, I chose the following options:

  • Quantity: 4. Enough for my two supervisors, my parents and myself. It seemed that ordering a fifth made the price higher than five times the cost per book when ordering four. Maybe they prefer to make batches of 4?
  • Size: 210x148mm A5.
  • Orientation: portrait (bound long edge).
  • Case (cover) type: custom full print colour. You can also choose a coloured cloth, but because I wanted to make a design for my cover I chose a printed form.
  • Corner protectors: no. These would look a bit silly on a full colour cover.
  • Ribbons: no. These are used for keeping your place in the book. They weren’t yet available when I ordered, but I may have taken them if had they been.
  • Headbands: no. These are little coloured ribbons that go above and below the paper block inside the cover. These would look weird alongside a glossy, printed cover.
  • Cover laminate: gloss. As noted in the guide, gloss cases are not the same as standard glossy photo paper. That stuff has a mirror-like sheen that looks pretty ugly on anything but colourful photographs. “Gloss” is the de-facto cover laminate for most new books, contrasting with “matt” which is the duller variety. This one is personal preference.
  • Hot foil cover: no. This is the gold or silver writing you put on standard theses. This only suits cloth covers.
  • Dust jacket: no. I decided it’s a bit pointless for a full colour cover to have a dust jacket: these are normally found covering cloth cases as a poor man’s full colour cover. It would only have been a few pounds more to order them, though, and you can always remove them if you don’t like them, so if you fancy it then go ahead.
  • Inner pages printed: mixture of colour & HiQ B&W. My thesis is mostly black text, but some pages have colourful graphics. If you don’t want a monochrome book, choose this, and you won’t regret the high quality black and white. When you select it, it asks for a count of the black and white and colour pages, so you’ll need to do that (just count the colour ones and subtract from the total to get black and white).
  • Paper type: 100gsm matt uncoated white. You can get thicker, thinner, shinier paper, but I went for standard and I’m very happy with it. If you’re publishing a chic novel you might want to go for cream.
  • Proofing type: PDF (online soft proof). This was the only option for me; it’s possible other options exist for higher order quantities. If you want a “real” proof to check everything looks good in print, you need to order a single copy with the same form. See the note on the PDF proof later.
  • Print, delivery, postcode service: tailor these to your requirements. I went for the (cheapest) defaults as I was not in a hurry.

My order ended up costing around £79 all-in, or just under £20 per copy. Considering that binding the single, “official” copy of my thesis for the library to the official university format cost £26 at one of the recommended companies, even having provided them with the printed pages to use, I consider that a pretty marvellous deal. That’s especially true given the creative control I was allowed.

Once you submit your order, the site works out how thick your book will be. Thicker books cost more to make and send, but more importantly you need the exact dimensions to use to design your case artwork in the event that you chose to make one yourself. The thickness of the spine is obviously determined by the number of pages and the weight of the paper, but also the type of cover you specify.

You are given an automatically generated note with your quote. In my case it said:

NOTES:
(1) Please make sure you read the online help explaining the differences between standard and high quality black and white printing.
(2) Spine width is approximately 21.8mm.
(3) Case artwork dimensions, height: 234mm, width: 345.8mm.
(4) Dust jacket (if ordered) artwork dimensions, overall height: 222mm, overall width: 491.8mm, front/rear cover width (each): 154mm, flap width: 77mm.
(5) If there is anything that you do not understand in this specification, please contact the helpdesk.
(6) Please make sure that you read the artwork preparation guide before placing your order.

So, my spine will be 21.8 mm. Given that I selected A5 paper, the case artwork needs to be equivalent to two A5 sheets next to each other, plus the spine, plus some extra bleed. For me, it was 345.8 × 234 mm (width × height). That budget breaks down as:

  • Two A5 pages: a single A5 page is 148 × 210 mm (width × height), so I need 2 × 148 mm in width, i.e. 296 × 210 mm
  • The spine: 21.8 mm, as defined above, added to the overall width, i.e. 317.8 × 210 mm
  • Extra 28 mm (width) and 24 mm (height) bleed, i.e. 345.8 × 234 mm. Note that you get grooves at the spine, where the glue that attaches to the inside paper ends, allowing for flexibility at the spine. This makes the actual A5 covers slightly wider. This adds to the extra width you need to account for.

The equations for the dimensions are, essentially:

  • Total height = book block height + 24 mm, so in my case the height is A5’s 210 mm + 24 mm = 234 mm.
  • Total width = 2 × book block width + spine width + 28 mm, so in my case the width is 2 × A5’s 148 mm + my spine’s width of 21.8 mm + 28 mm = 345.8 mm.

    The “hang over” of the cover over the book block. This is an extra 4 mm of material that helps to protect the pages of the book.

The extra 24 mm (height) and 28 mm (width) are required to allow the design to fit the cover. The budget for the extra width (28 mm) breaks down as:

  • 8 mm used to wrap the cover artwork around each edge of the book (16 mm total)
  • 6 mm used to allow the cover to “hand over” the paper, and to allow for extra material for the two “grooves” at the book’s spine (12 mm total)

The budget for the extra height (24 mm) breaks down as:

  • 8 mm used to wrap the printed design around the edges, as above (16 mm total)
  • 4 mm above and below the book block height to allow the cover to “hang over” the paper

Step 1: design the cover

If you choose to provide custom cover artwork like I did, you need to create a PDF of the correct size and upload it alongside your book block. Fortunately, Inky provide a video tutorial showing how to achieve this with the free, open source design software Scribus. Fantastic! It’s easy to set the dimensions in Scribus using guides, which help to define the area you need to provide artwork for, and show what will and will not be visible on the front, back and spine of the book. The video walks you through calculating the dimensions of each part of the cover (as I also listed above), so you’re finished with a grid of guides showing each area.

Guides for my A5 book in Scribus. In addition to the standard margins, I added guides to show the horizontal and vertical centre lines to assist with placing text and graphics.

Of course, the trickier bit is actually coming up with a cool cover design! For that, you’re on your own, except a note that you should design your cover with the back on the left, so that when folded over the book the text still reads the right way up.

Here’s what I came up with:

My thesis cover design.

I’m no design pro; I have the creativity of Status Quo when it comes to art. I included the usual stuff: the title and my name on the front cover and spine. I also added a generic picture related to my work*, prettified for the front cover with the removal of the labels, tweaking of axis limits and the use of a nice complementary colour wheel (it took a very long time to render, but that’s a story for another time). Tempted as I was, I decided against adding the thesis abstract to the back – this is not a novel. I managed to find a nice vector graphic of the university’s logo, so I added that to the front cover opposite my name. The background is a nice bold blue – my favourite colour. I’m quite happy with it!

*For anyone that is wondering, it shows a surface map of the power of the error signal from the second RF control sideband in the signal recycling cavity of ET-LF as the Schnupp asymmetry and exact cavity length are tuned (see Chapter 7).

Step 2: compile the pages in A5 format

I spent over half a year writing my thesis, formatting it for A4 paper as I went along. LaTeX, however, takes most of the control over page layout away from the user and uses algorithms to decide where to place text, figures and everything else. This generally works quite well, but occasionally has issues, especially when your text is figure-heavy. I found that changing the paper size from A4 to A5 led to some unintended blank pages at the beginning or end of chapters and sections, and small figures hogging their own page. Some of these issues were because of blank pages I had added when it was formatted for A4, which were no longer appropriate for A5, so let’s not blame LaTeX too much. Some of them, though, necessitated moving the figure definition in the source code to force LaTeX to alter its positioning behaviour, which is a bit more time consuming.

I had to go through the whole document and fix these as they occurred. To prevent wasting time in a recursive doom fixing one part and breaking another, I did this sequentially from the start. Whatever you do, don’t just fix layout issues at random as you find them – you’ll no doubt break the layout later in the document.

Naturally, going to a smaller paper size while maintaining the margin and font sizes leads to extra pages. Going from A4 to A5 in my case, the page count went from 244 to 271 – not as much a jump as I expected. As I did not alter the text size, the relatively small increase in page count is probably due to the page-spanning figures taking up less physical real estate where otherwise text could go. Put another way, the ratio of the graphic dimensions to the text dimensions was reduced.

Step 3: upload the sources and proof the full book

The PDF proof of my book generated by InkyLittleFingers. The cover is naturally larger than the rest of the book, as it has to wrap around the two cover pages and spine. The proof contains bleed marks, where the paper will be cropped after printing (to allow graphics to “bleed” over the sides of the paper, so that when it is cut the graphic is flush with the edge).

After creating the order (and paying!) you need to upload your work. The book block (the pages of the book) is uploaded as a separate document to the case artwork. In my case, the book block was a PDF compiled with LaTeX, and the cover was as PDF exported from Scribus. I thoroughly examined these documents before uploading, but the main check to make is of the automatic proof that InkyLittleFingers generate for you after uploading. It contains the case artwork and book block rendered as you will see them once printed: with the colours set, the pages appropriately sized, the fonts chosen and the images appropriately cropped. Check this proof thoroughly – this is exactly what you’ll see, minus the marked bleeds, when your printed books arrive.

In my case, the automatic proof contained a few small artefacts on some diagrams. I phoned Inky to verify where this was coming from, as I was not sure if this was just an effect of my PDF viewer. It turns out that they were real, and somehow produced by their systems: the book block I uploaded did not contain these artefacts, but only the proof generated by them. In hindsight, though, I doubt it is a bug with their own software, but rather some bug with the way that the Adobe PDF format handles embedded graphics. The worst artefact I found was in a graphic that was itself a PDF embedded within the PDF book block. This was originally generated with Inkscape using a library of SVG parts themselves made with Adobe Illustrator. Somewhere along this myriad format conversion process something happened that led to this artefact in the final version.

One of the minor artefacts in a vector graphic within the book block. The beam splitter – designated “M6” – should not have pixellated edges. Indeed, the source file I generated the graphic from does not have this artefact – it’s only when I got the proof from InkyLittleFingers that it appeared.

I never found out the culprit for the artefacts, but I did manage to get rid of almost all of them by playing with the SVG sources in each case. Flattening images from many layers to one, and merging overlapping segments were two strategies that seemed to work.

The nice thing about the Inky interface is that you can continually upload new book blocks and case artworks and generate new proofs until you are happy. I did this at least three times, gradually getting rid of all of the artefacts, until I was happy. In the end I left the worst artefact in, as I had managed to make it better than to begin with and it was very, very minor and hardly noticeable. My last hope was that it would not appear in the final print despite the proof.

Once you sign off on the final proof, Inky get to work making the book. Now the waiting begins!

 

Results

After about a week, I got the books in the post. Accompanying the delivery was a note saying that I should wait at least 12 hours before opening the pages fully; they are apparently immediately dispatched after production so there’s a chance the glue might not have fully set if the delivery was unusually quick. I was so eager to look at my creation that I did open one copy – the one I intended to keep myself – and it seems in hindsight that it didn’t do any damage.

The black and white pages were printed to very high standard.

The quality is superb. The whole book seems tough and durable. The book as a whole feels sturdy. The glue is neatly applied to the paper block, which is firmly glued to the inside of the case, over the edges of the cover which are tucked properly in place. It easily sits free-standing on its narrow side, able to sit on a shelf and support its own weight. The binding of paper and cover has been achieved flawlessly, and the book block sits exactly in the middle of the cover. The paper quality is great. The print fidelity on the black and white and colour pages is equally excellent. I am extremely pleased and impressed with the results, especially given the price I was charged.

The artefact mentioned above was, while present in the final print, hardly noticeable (see photo below). It was more than offset by the superb print quality for the diagrams and images (and indeed text!).

Highly recommended!

Spectra Microvision Plus install guide for modern operating systems

The Spectra Microvision Plus is a nice residual gas analyser (RGA), allowing one to examine the elements and molecules present within a vacuum system. In the speed meter group at the Institute for Gravitational Research, we use it to test our vacuum system for cleanliness, leaks and the presence of unwanted elements before we place our delicate optical surfaces inside and shine high power lasers upon them.

Spectra Microvision Plus. This box is able to analyse the residual gas profile of a vacuum system, but it’s tricky to install the aged software on modern machines.

Despite being around 15-20 years old, this hardware is solid and still works nicely. The problem is that the software used to control the box is a similar age, and has well and truly suffered from bit rot. In fact, it came with the unit in the form of three floppy disks. These were old even when I was growing up, and CDs and later DVDs became the standard distribution channel for software. Adding insult to injury, the software is only designed to work on Windows 3.1 (!), 95, 98 or XP, meaning any modern computer is going to struggle to run it. Finally, it demands a physical RS-232 connection to the machine, since it harks from the days when USB was but a teenager with braces and oily hair, and Apple and IBM were still preventing one standard from ruling them all by pushing FireWire.

Incidentally, if you’re looking to download the Spectra RGA For Windows software that is used with the Spectra Microvision Plus, it’s unfortunately not available directly from the manufacturer. They apparently insist on users paying $2k for newer hardware. If you want the software, though, just send me an email – I’ve made images of the floppy disks for safe keeping.

Spectra RGA For Windows software running on VirtualBox on a Linux host

I managed to get the software to work by using VirtualBox to emulate Windows XP on a Linux host. I run Ubuntu on my machine, so VirtualBox is easily installable via the package manager. Fortunately, my university still has XP campus licences kicking around, so I fired up an ISO and installed XP as a virtual machine within VirtualBox. If you need to know how to install XP on VirtualBox, just google it. If you run Windows or Mac OSX, don’t dismay – VirtualBox is also available on those platforms, so this will still work provided you can obtain a Windows XP disk or image.

Interface to RS-232

Now comes the slightly more tricky part. As stated earlier, the RGA uses RS-232 for communication between the hardware and the RGA For Windows software, and modern computers don’t come with RS-232 ports. However, given that USB is, eponymously, universal, you can buy an adapter which emulates an RS-232 serial interface over USB for a few pounds:

RS-232 to USB adapter. Could it be any simpler?

I got mine from StarTech.com, but you’ll find them anywhere with a quick search. Ubuntu 16.04, but probably all recent Linux kernels, supports this adapter out of the box, giving you a virtual RS-232 port that you can hand over to the virtual machine.

If you use Ubuntu or a Debian derivative, make sure your user account is part of the “dialout” group (run usermod -a -G dialout [your-username] as root, then log out and back in again), otherwise you won’t be able to read from and write to the serial adapter.

Once you’ve got an RS-232 USB adapter, plug it in and fire up VirtualBox after having installed Windows XP. Before starting the operating system, however, you need to tell VirtualBox to pipe the RS-232 connection through to the virtual Windows XP system. In the settings for the Windows XP virtual machine, go to “Serial Ports” and enable Port 1. Then choose “COM1” for the port number and “Host Device” for the port mode, assuming that your kernel has successfully identified the adapter (run dmesg in a terminal and look at the kernel messages to check). Put /dev/ttyUSB0 as the Path/Address, but check that this is actually the path to the serial adapter you plugged in (again, use dmesg or similar to find out). Once this is done, you should be able to fire up Windows XP and look in the device manager to see a new COM port present.

Installing, configuring and running the RGA For Windows software

Given that the software was distributed on floppy disks, I first had to get a USB floppy disk drive and create images for each of the three disks (using dd in the terminal – again, Google is your friend). VirtualBox can mount these images in turn, allowing your virtual Windows XP machine to think it actually has a real floppy disk drive attached. I inserted the first “disk”, opened up “A:” in Windows and started “INSTALL.EXE”. It is very simple: after clicking next a few times and inserting the second and third virtual floppy disks when asked, it was installed.

To get the software to run, the first thing to do is to run the “Configure” program from the start menu. For me, it found the only COM port configured on the computer (COM1) and was happy. After that, fire up the “RGA” software with the RS-232 connector plugged in to the Spectra Microvision Plus unit. You should be presented with the default screen – hurrah! – and after that, you can take some measurements. Here is a screenshot of the RGA For Windows software running on a Windows XP virtual machine, itself running on Kubuntu 16.04:

The Spectra RGA For Windows software running on a virtual Windows XP machine, running on an Ubuntu host.

There we go! A virtual machine that is able to talk to the Spectra Microvision Plus RGA, future proof and fit for modern operating systems. Hopefully this allows this old but solid hardware to continue to serve a purpose in modern research labs. Let me know if you run into any issues when getting the software to work – I’d rather not let Spectra hustle thousands of dollars out of customers just by refusing to update or release 20 year old software…

First Detection of Gravitational Waves!

tl;dr: we have detected gravitational waves! Read our paper in Physical Review Letters here!

Update: we hosted a Reddit Ask Me Anything (AMA) session over the past few days. The reception was incredible and we tried to answer as many questions as we could. Take a look at our responses!

Back in 2014 I wrote about the supposed discovery of gravitational waves from the BICEP2 project in the Antarctic. This experiment was looking for echoes in the microwave spectrum from the Big Bang in the form of primordial gravitational waves, hoping to uncover evidence of inflation: the rapid expansion of the universe that helps to explain why the universe now appears to be so uniform. This evidence was thought to have been imprinted as a distinct pattern in the polarisation of the cosmic microwave background measurable from Earth with highly sensitive instruments.

The BICEP2 Observatory in the Antarctic. By Amble (Own work) [CC BY-SA 3.0, via Wikimedia Commons

The BICEP2 Observatory in the Antarctic. By Amble (Own work) [CC BY-SA 3.0, via Wikimedia Commons]

Einstein’s missing jigsaw piece

As the last untested theory of Albert Einstein’s 100 year old General Theory of Relativity, the discovery of gravitational waves would have been big news. Unfortunately, it turned out that the evidence for the waves and inflation the researchers thought they saw in the data was actually a calibration error. The effect of cosmic dust clouds had not been fully understood and removed from the data, and it turned out that this was a significant oversight. Later measurements from the Planck satellite ruled out BICEP2’s conclusions entirely.

During the eventful few months while the academic community scrutinised the BICEP collaboration’s findings, I was very hopeful that my own collaboration, another group searching for gravitational waves, would have firm proof of their existence before beginning our first advanced science run after 5 years of upgrades.

As part of the Institute for Gravitational Research at the University of Glasgow, I am a member of the LIGO Scientific Collaboration (LSC). We are collectively a group of 1000+ scientists from 80 institutions in 15 countries dedicated to the efforts to build giant gravitational wave detectors on the ground and in space and to analyse the terabytes of data they produce. I work on instrumentation, where I am investigating alternative interferometer topologies, simulating the control schemes for future detector designs and measuring new types of mirrors (more information on my academic website). My colleagues in Glasgow – one of the largest individual groups within the LSC – work on a variety of other topics, including low-noise coatings and suspensions (something of a Glasgow speciality) and data analysis techniques.

A fortunate signal

Binary black hole merger artistic impression kindly provided by Aurore Simonnet, E/PO Sonoma State University

Binary black hole merger artistic impression, kindly provided by Aurore Simonnet, E/PO Sonoma State University

In September 2015, our first science run was due to begin. O1 was supposed to start on September 14th, but after an “all-hands” telecon was called to determine observation readiness, it became apparent that a very minor aspect of the software – one which in no way affected the detector sensitivity or the validity of its data – was not fully implemented. As some of us had been waiting years, or even decades, for such a sensitive science run to start, it wasn’t a difficult decision to postpone the start of the run for four days. As luck would have it, however, the first gravitational wave detected on Earth was in fact detected by the interferometers on the day the run was originally due to start – September 14th! Luckily the detectors in Hanford (Washington State) and Livingston (Louisiana) were exquisitely locked and fully sensitive, ready to hear the ringing of two coalescing black holes loud and clear. The logbook entry from the morning of the event read: “Operating Mode: Observing. Range: 68 Mpc. Seismic is quiet; weather is clear.” In this pre-observation period only a few days before the official start of O1, the detectors were for all intents and purposes in “observing” mode, with only some calibration issues to iron out, so they were completely capable of detecting gravitational wave signals. The only confusion at that time was because we were not expecting a signal so wonderfully clear! How could such a loud and clear event be real!? See for yourself:

In the days and weeks following the detection the main focus was on gathering enough background data to determine the event’s false alarm rate – a task designed to answer the question: “how likely is it that this event is just an unfortunate instance of noise, given the characteristics of the detectors?”. To answer this question, we need a hell of a lot of data. Server farms in the USA and Europe crunched numbers constantly for days and weeks, racking up 50 million CPU hours, eventually determining the false alarm probability was low enough to merit a detection reaching the fabled 5 sigma status.

Belief

There was not an immediate realisation, at least from my experience, that we really had made the first ever direct detection of gravitational waves. After the first flurry of emails on September 15th and the masses of labbook and mailing list entries in the days following, we gradually started to rule out more and more possible false alarms and it became more and more clear that something special had been observed. The point at which a lot of collaboration members really started to believe the signal, including me, was three weeks after the event when the results from the false alarm analysis were unveiled. This process necessarily involves a “closed box” analysis where the researchers look at auxiliary data channels from the detectors in order to remove any known false alarms (no Schrödinger’s cats here). The idea is that obvious, accidental or intentional noise transients are removed from the data to get a true idea of the false alarm probability of the detectors themselves when they are left alone. When commissioners stomp too heavily near the detectors or cars rumble past too quickly, this data is identified in auxiliary channels and removed from the data. This process must, to avoid human bias, be conducted blindly without reference to the putative event. In doing this, we can be confident that we have treated the noise analysis fairly and can claim the detection statistic we calculate as scientific fact.

Final black hole size, with Europe for comparison (credit: Chris North, Cardiff University)

Final black hole size, with Europe for comparison (credit: Chris North, Cardiff University). Look out, Norway!

Human nature

The procedure laid out long before the detection asked that the collaboration spokesperson – Gaby Gonzalez – appoint a paper coordination committee tasked with gathering the results from the analyses and writing the text of the scientific journal article to be submitted in due course. Once Gaby had put together an experienced team of collaboration members to coordinate the production of the paper, the task presented to all of us was to help write, read and scrutinise the draft as it was moulded from a smattering of statements and plots into a manuscript to be read by scientists for decades and perhaps centuries to come. A mailing list was set up for discussion to take place, and this proved to be extremely popular. As a PhD student I am fairly inundated with emails as a normal part of my day, but membership of the paper coordination mailing list instantly tripled my daily haul. While most of the discussion was merited, the occasional mundane issue was mercilessly wrangled to the point at which I would mark entire threads of emails as read without actually opening them. But, chaotic as this seemed, the paper coordination team managed to assemble over a dozen drafts which were each refined to a greater extent than the last until we were left with something which, in my opinion, is an exquisite single malt of a paper that will stand the test of time. I am truly grateful to the team for managing the barrage of scientific, clerical and grammatical discussion flying back and forth across the Atlantic.

Over that period, an aspect we had to contend with that I had not expected was leaks to the public. Only a few weeks after the event the news spread on social media that we had detected something. While this particular news was only speculation, it did win clout in the form of a tweet from a famous astronomer. This did not help our efforts, as increased public speculation pressured the paper team and data analysis colleagues within the collaboration to hasten the analysis and cut corners: something which none of us wanted to do. Numerous reminders were sent to the entire collaboration asking us to be careful with paper drafts left in printers, discussions with friends, family and colleagues not in the collaboration, and email recipients. I think the initial social media leaks could be blamed on accidental, over-exuberant conversation from excited scientists – something most of us are probably guilty of. Later, however, the public at large started to learn more and more information about the event that could only have been gained directly from collaboration members. Unfortunately I witnessed some individuals claiming to be members of the LSC posting on websites like Reddit with details of the event. One such poster stands out in my mind because they chose the username “LIGO_mole”. How crass. Fortunately, in some part due to the discipline of the rest of the collaborators and in another part due to the noble decision taken by the professional media to avoid partaking in mere speculation, the spotlight moved away from us and we were able to continue the paper discussion and analysis unimpinged.

Finally public

As the holidays passed in 2015 and we moved into the new year, a full century after Einstein’s work was published, we geared up to tell the world of our wonderful findings. Now that you are reading this article the news is public. I had very little to do with the whole process – though I would like to think I will be involved in future detector designs and discoveries – but it has been a fascinating journey and I am extremely grateful to have been a part of such a wonderful piece of history. Here’s to the LIGO, Virgo, GEO, KAGRA and, hopefully one day, eLISA: the gravitational wave detectors of the present and future. Long may you listen to the cosmic symphony of space time, and let us open up this new window into the universe and gaze upon the innards of black holes, supernovae and neutron stars! Huzzah!

Read our paper!

More information

There are a whole bunch of other blog posts from LIGO Scientific Collaboration members which you should take a look at:

Martin Hendry, our head of school in Glasgow and a fantastic proponent of public outreach, wrote an article for The Conversation which has been picked up by Time Magazine.

Please also take a look at my academic web page, some interesting Twitter accounts (@LIGO, @martin_astro, @BeckyDouglas, @GlasgowGist, me!), gwoptics.org and the official LIGO website for more information.

Online Labbooks for Scientific Research

Over at my workplace, the Institute of Gravitational Research at the University of Glasgow, we undertake lots of experimental research (primary physics) and produce lots of data. For the most part, this data is saved on individuals’ computers (centrally backed up but only accessible to that user), a shared hard drive on the (Windows) network, or written in paper labbooks (though these do have serial numbers for archival and accountability).

In my group, Stefan Hild’s European Research Council funded Speed-Meter experiment, we were slightly ahead of the curve. My interferometry colleagues and I for many years used a simple SVN-based labbook that involved placing a text file called “Notes.txt” and any images associated with the post into a directory with the current date. This was then parsed by a simple web interface to provide an online labbook that could be viewed by anyone on the network with the URL. It worked quite well, and was certainly better than a paper-based labbook in most regards, but it lacked a few key features:

  • Ability to link to previous labbook posts directly (via URIs/URLs): we instead had to quote the labbook title so that the user, if they were interested, could find the referenced labbook post.
  • Users: we used a single login for the SVN to add posts, all which which were marked as having been uploaded by “jifadmin”. It was only possible to tell who made a post by context.
  • Categories: the ability to group posts together in logical sets.
  • Versioning: otherwise known as “keeping track of edits”. We kind of hacked this to work with the use of the SVN, but the ability to roll-back or view a diff of two files involved the use of a separate system (command line or GUI).
  • Image/media upload: display of in-line images in posts, where they would logically go. Instead, our images always appeared at the bottom of the post and we would have to reference them by file name in the appropriate part of the post.
  • Centralised user credentials: this was part of a wider issue in the group which was gradually getting better. We would require a login for the SVN to add content to the labbook, but also a different login for other services like email, WiFi and the shared calendars.

We put up with this system for a number of years, but eventually when we started a major project we ditched it and turned to some software called ‘OSLogbook’.

Open Source Logbook

Imaginatively named ‘OSLogbook‘, this software is used in the Virgo and LIGO collaborations, which are scientific organisations that we are members of and frequently collaborate with. This brought a number of new features to the table:

  • LDAP login: centralised login system using centralised credentials, via the LDAP protocol.
  • Categories and tasks: each category can have subtasks, and each post can be assigned a single task within a category.
  • Authors: each user has their own login and can post their own content that is marked as their own.
  • HTML posts: a basic WYSIWYG editor allowed us to add headings, tables and coloured text to our entries.

We used this for a couple of years and found it useful, and a vast improvement over the SVN-based labbook. However, it still annoyed us in a few places and had some quirks which were not intuitive. For instance, posts could only be assigned to one category. In our daily work we often conduct lab work or experiments that involve multiple aspects of the same experiment, such as the organisation of power supplies to various corners of the lab or temperature and humidity changes affecting sensitive measurements.

The labbook also allowed us to assign multiple authors to each post, but in the form of a text field. That sounds useful at first, but it’s actually a pretty bad way of implementing this feature. If a person makes a labbook entry and puts their name before another collaborator, and the next day the other collaborator puts their name before the first collaborator, that author list is then a different set of characters despite containing the same names! Searching for posts by a certain author was therefore difficult because you don’t know in which order their name appear. Furthermore, it was left to the whim of the author of each post to correctly specify the names of their collaborators, meaning that occasionally a nickname or mis-spelling found its way into this field.

Perhaps the weirdest feature was that comments made on each labbook entry actually showed up as their own labbook entry. The list of labbook posts therefore contained in chronological order the comments made on each post as well as their respective posts – meaning the homepage was a cluttered mess of crossing conversations.

Not good.

The sum total of a number of small niggling issues with OSLogbook led me to investigate an alternative. We wanted our alternative to have the following features, in no particular order of importance:

  • Centralised login system: using our already-established LDAP system to authenticate users.
  • Permission system: we wanted our summer students and undergraduates to contribute to our labbook, but not be able to mischievously edit or delete other users’ posts.
  • Comments: labbook entries in an experiment with dozens of members more often than not require organised discussion. A comments system allows each user to contribute their thoughts in a coherent manner, without making a new labbook entry as a follow-up.
  • Media upload: beyond images, but also for zip files, analysis and plotting scripts, PDF documents, etc.
  • Rich text editing: we wanted to be able to add tables of data, links, coloured text, lists, special characters, centrally-aligned text… every little detail. Don’t constrain the user in making a post as clear as possible.
  • Multiple authors: the ability to assign a post to multiple authors, and allow any of those authors to further modify the content, and to have all collaborative posts an author is part of show up in a search of that author’s posts.
  • Reference pages: the ability to create static pages with reference information that does not fit in a labbook post. For instance, a list of procedures for ordering equipment or links to useful intranet/internet pages.
  • Ability to add new features: ideally, rather than a black-box monolithic software like OSLogbook, we wanted to be able to modify the software to fit our needs. There are a few programmers in the group, so with a nice API it would be able to tailor the labbook the way we want it.
  • Looks nice: people don’t read ugly websites unless they really have to. Let’s not make it difficult!

The obvious choice: WordPress!

Almost all of these features can be found on full-blown news sites, blogs and other content mills. It turned out that the popular blog software WordPress fit the bill… with the help of some plugins. Its vibrant community and extensive theme and plugin support made it a no-brainer. However, it lacked a few of the desired features that would not necessarily be useful on full-blown sites, but useful to a scientific organisation, like multiple authors and LDAP support. Before taking the plunge and moving my colleagues over to the system, I had to research whether there were plugins that could help us meet our list of requirements. In the end, the huge WordPress community delivered. There were plugins or native WordPress settings for all of our desired features!

Implementing Desirable Features in WordPress

This section is a guide to the plugins required to implement cool features, listed below, in our labbook software. The same plugins should work for anyone wishing to build a scientific labbook.

Multiple authors

As described above, we wanted to be able to assign multiple authors to individual posts, and allow these posts to show up in searches of any of the individual authors of that post. This can be achieved with the Co-Authors Plus plugin – and it does exactly what we want! After a single author finishes writing the post, they can start typing the names of their collaborators. As they type, other registered users with names matching the text spring up and can be assigned authorship. If a user is named as an author on a post, they can then edit it. This lets users create and edit any post they are named as an author on, but not necessarily edit other posts should you not wish them to.

Mathematical markup in posts

As a scientific group, we frequently share mathematical equations with one another. The plugin MathJax-LaTeX lets us type LaTeX equations in our posts and displays them in-line. It also utilises MathJax rendering, which displays in modern browsers nicely and allows the corresponding LaTeX code to be copied-and-pasted.

Email alerts for new posts and comments

We wanted to have the option of receiving an email alert when a new post or comment was made. Somewhat surprisingly, this is not a standard feature of WordPress. A Google search will probably point you towards JetPack, but this plugin is too bloated for what we require – it’s focused on commercial sites and making money, not a simple task like notifying registered users via email.

Email Alerts

Some users wanted alerts via email when new posts and comments were made on the site. This was accomplished by using the already built-in feature of WordPress, RSS (“Rich Site Summary” or “Really Simple Syndication”), which allows an external feed-reading service to download a copy of the recent posts on the site and send a digest to a user’s email address. Perfect, right? Not quite. Our labbook was to be private – scientifically sensitive measurements were under discussion – so external feed readers would not be able to access the RSS feeds by default. This hurdle was overcome by the plugin Private Feed Keys, which allows users to create a special URL which allows external readers to download RSS feeds. This doesn’t require a login, but each special URL is unique to each user and can be given to a trusted feed reading service (most of us use Blogtrottr).

 

With our plugins sorted, we still had to do something about the old labbook content. Since we had used our old labbook for two years, we had plenty of content already on it that we would not want to lose. We couldn’t just delete it, so I had to investigate a way to transfer the old content across.

Importing posts from old labbook

The number of posts was not so high (roughly 250, including comments) that it was beyond the scope of hacking together an import script. WordPress also has a nice API to allow a PHP script to directly create posts in the WordPress database – so I was able to create a script to extract the old posts from the OSLogbook database and inject them in to the new labbook. Comments were a little trickier, as were image and file attachments – but I managed to do it in the end with a mix of crafty PHP scripts and some elbow grease!

Styling the new labbook

The last job was to make the labbook look great. As I said earlier, people don’t like to use nasty looking sites with bad user interfaces. Luckily, WordPress is of course designed for ease-of-use, so we already had a great default theme. To allow the site to operate more like its intended labbook and less like a blog, we adopted the theme Simple Life and modified it slightly for our particular purposes. This led us to create a child theme (see it on GitHub) and a custom plugin or two to provide specific functionality that we wanted:

  • A recent edits widget to show any posts that were recently modified, to keep track of changes across all content (GitHub page)
  • A widget containing a list of comments and links to recent SVN commits (GitHub page)

Our awesome labbook

This is our labbook:

Our Speedmeter labbook software in use.

Our Speedmeter labbook software in use.

Pretty cool, huh?

Since we made the labbook, it has garnered the attention of other colleagues in our group who have since adopted similar blogs. The IT manager simply uses WordPress’s network administration tool to create a new site in seconds and clicks a few buttons to enable the plugins we use.

I hope this guide will be of use to the wider academic community and the science industry. You don’t have to suffer with poor labbooks!