Previously on this blog, my colleagues Carlos and Eoin have extolled the many virtues of Singularity, which I will not repeat here. Instead, I’d like to talk about a rather interesting subject that was unexpectedly thrust upon me when my faithful Linux laptop started to show the early warning signs of critical existence failure: is there a good way to run a Singularity container on a pure Windows machine? It turns out that, with version 2 of the Windows Subsystem for Linux (WSL), there is.
Continue readingCategory Archives: Hints and Tips
Lessons in Scientific Code Deployment
So, I recently deployed my first piece of scientific code. Well, sort of. I made a github with instructions on how to download, install and run it.
And then everyone broke it.
So, now having been on tech support duty for a few weeks, it seemed like a good idea to have a think about what I’ve learned.
Now, there is a big preface to this: the first and most important thing I learned is that I should do some reading on how to do this well. I have not yet done that reading, so this post isn’t so much going to offer any advice as catalogue my mistakes. Mistakes that will probably look extremely silly to anyone who has any familiarity with deployment, but might be interesting to anyone who doesn’t.
A surprising number of people really don’t want to touch the command line
Being a programmer who spends the vast majority of their time on the command line, invoking programs from there is very natural. As such, I very much underestimated the obstacle that even installing anaconda, a few packages, and cloning the source code would be. Even with instructions to copy and paste.
The issue is, if anything goes wrong, there is a good chance they don’t know whether it is my code or their environment breaking, which probably means they need to contact me about it (more on environments later).
Really, I probably could have saved myself an awful lot of support by making it an installable, and more with a gui to guide people through using the program.
Python is a pain
So, the first thing I learned was something I’d kind of been warned about: deploying python code is a pain in the butt. Especially to people who aren’t familiar with python, managing python environments is both tricky and overwhelming easy to break code with. Run a python script from the wrong environment and it is going to fail: if you are lucky with a failure to import a module, if you are unlucky with a cryptic error due to say changes between various python versions.
Speaking of python versions, developing in 3.9 and not testing in 3.7 then telling people to install that can result in a surprising number of surprisingly difficult bugs.
The instructions weren’t clear enough
Scientific code I think generally caters an awful lot to expert users, people who really understand the model and even are willing to open the source code to figure out the implementation.
My first stab at documentation managed to not be clear enough to the people who didn’t want to touch the command line and those who were willing to open the source code because they wanted to do something spicy.
So yeah, good documentation is an acquired skill.
Distributed computing is a nightmare
In principle, distribution is terrific: get a library that will allow you to reduce running arbitrary python code on multiple nodes to a simple map-like interface. On big clusters, like a lot of scientists use, this can mean speed ups from 10 to even 1000 times.
The only problem is, everyone’s cluster is a special snowflake, and you can’t access most of them to fix things. This can make iteration with a non-programmer painfully slow.
Libraries don’t help as much as I’d have thought either: indeed, my experience of Dask and Dask Jobqueue has been a consistently uphill battle. From the fact that my workload likes individual nodes sharing lots of memory and a few cpus to some truly arcane errors (one that broke in the msgpack code), I have generally considered (and even started) writing my own code to do this.
Active development doesn’t reach people
Code that is being updated several times a day in response to bugfixes can be great – but if people aren’t pulling and installing it, no-one is going to benefit. I’m seriously tempted to write some code to either auto-update on running or at least let folk know it has been updated.
Summary
In summary, a lot went wrong in my first stab at this. Very much come to appreciate a good deployment is an artform, and I’ve got an awful lot of reading to do. In particular, the above problem areas really have eaten a lot of time that probably could have been used doing actual science with the code, so there is a good incentive to get it right.
Making your python tool as easy to install as possible
Have you ever tried to use someone else’s code and spent a whole day trying to install it? Have you ever decided not to use a tool because installing it was a massive pain? Both of those have happened to me and, to be honest, it is a massive shame. The authors may spend large amounts of time developing these tools and in the end, no one uses them because they can’t get them to work. So I have decided to try and make all code I develop as easy and painless as possible to install and use.
Continue readingLinux Horror Stories and Protection Spells (Volume I)
Don’t get me wrong. I love Linux. After many years of using it, I ended up appreciating how flexible, potent, and even beautiful it is. However, using Linux has never been a bed of roses and every single Linux user that I know has had to deal with many problems since the very beginning. Indeed, I still remember how frustrating installing my first Linux machine was, especially after realizing that my network card was not working. Had I given up, I would never have written this post.
Although many of the problems that I faced while using Linux are related to updates and drivers (how painful NVidia drivers updates can be, I will write another post about that in the future), I must recognize that on many other occasions I was the only one responsible for such problems. Consequently, I want to warn the reader against a couple of those mistakes I made in the past and provide some tips about how to deal with them.
My worst nightmare: rm –r *
Singularity: a guide for the bewildered bioinformatician
Have you ever worked with a piece of software that is awfully difficult to set up? That legacy code written on FORTRAN 77, that other one that requires significant modifications to compile, or any of those that require a long-winded bash script with a thousand dependencies (which you also have to install!). Would it not be helpful if, when that red-eyed PhD student, that one that just spent three months writing up their thesis, says that they absolutely must use that server where you have installed all your stuff, you could just relocate to another one without trouble? Well, you may be able to do that now. You just need to use containerization.
The idea behind containerization is rather simple. The best way to ensure anyone can reproduce your work is to, well, ship your entire system to whomever needs to use it. You could, for example, pack up your desktop in a box, and ship it to your collaborators anywhere in the world. Unfortunately, this idea is quite unpractical, not only because of tedious logistics (ever had to deal with customs?), but also because suddenly you won’t be able to run your own pipeline. However, it is a good enough thought that at some point made a clever engineer wonder whether there was a way to ship an entire system without physically delivering the computer. And that’s exactly what they designed.
Commercialising your research: Where to start?
If you look at some of the biggest technology companies in the world, from Google and Facebook to hardware companies like Dell or even biotech unicorns like Oxford’s own Oxford Nanopore, all of them started on university campuses. If you are a researcher interested in finding out how to make the first steps to commercialise your research here is a quick guide:
Continue readingPeer Review: reviewing as an early career researcher
Peer review is an important component of academic research and publishing, but it can feel like an opaque process, especially for those not directly involved. I am very fortunate to have been able to participate in the peer review of multiple papers, despite being very early in my career, through support from my supervisors and a mentoring program run by Sense about Science with Nature Communications. Here are some of the things I have learned.
Continue readingTo Pickle, Or Not To Pickle? — Quickle!
Pickling in Python can be dangerous.
That’s where Quickle comes in — as long as you’re using Python 3.8 or later…
Making Pretty Pictures with PyMOL
There’s few things I like more in our field than the opportunity to make a really nice image of a protein structure. Don’t judge me, but I’ve been known to spend the occasional evening in front of the TV with a cup of tea and PyMOL open in front of me! I’ve presented on the subject at a couple of our research group retreats, and have wanted to type it up into a blog post for a while – and this is the last opportunity I will have, since I will be leaving in just a few weeks time, after nearly eight years (!) as an OPIGlet. So, here goes – my tips and tricks for making pretty pictures with PyMOL!
Ray Tracing
set ray_trace_mode, number
I always ray trace my images to make them higher quality. It can take a while for large proteins, but it’s always worth it! My favourite setting is 1, but 3 can be fun to make things a bit more cartoon-ish.
You can also improve the quality of the image by increasing the ‘surface_quality’ and ‘cartoon_sampling’ settings.
BioDataScience101: a fantastic initiative to learn bioinformatics and data science
Last Wednesday, I was fortunate enough to be invited as a guest lecturer to the 3rd BioDataScience101 workshop, an initiative spearheaded by Paolo Marcatili, Professor of Bioinformatics at the Technical University of Denmark (DTU). This session, on amino acid sequence analysis applied to both proteomics and antibody drug discovery, was designed and organised by OPIG’s very own Tobias Olsen.
Continue reading