The Bioinformatics Support Unit has been operating for over eight years now, and for all of that time we’ve run under a ‘cost recovery’ model. The faculty understands that in order to be a cutting-edge medical school (that’s research-led) we need certain essential services. In return, we understand that the faculty cannot just write off the costs of running those facilities as a loss-leader (however much we would like it too), so we have to make the commitment to recover as high a proportion of our operating costs as we can.

What this means, in practical terms, is that it is very hard (although not impossible) for us to undertake unpaid work, as this would systematically reduce the time we have available to meet the cost recovery commitment we have made. It also means that by far the best way to make maximum use of our services is to consider your bioinformatics needs at grant time, and include us in your application. This has two effects: (1) you get proven bioinformatics expertise in at the start of your application, and a named investigator to carry out the work and (2) you get to make sure the experiments you are proposing are best able to meet the demands of the data analysis required to make meaning of them further down the line.

What this doesn’t mean is that we have to charge for every single second of every single day – we do not operate like lawyers, starting the stopwatch as soon as someone steps in the office, and billing for every moment thereafter by the minute. I would never bill someone for a conversation, or for offering advice. I would also far rather researchers came to have that conversation about their bioinformatics requirements than try to muddle through and get frustrated because they’re worried about a bill they or their PI won’t be able to foot. Despite our cost recovery requirements, my primary motivation as facility manager is to help improve the science output of the faculty as best I can, not recovering every possible penny from every interaction.

So just what do we charge for our services? Our rates are based on full economic costs, and are determined by the university finance office according to complicated criteria that I don’t entirely understand, but what that leads to is rather simple: a single hourly rate for ‘analyst time’, which is £59.12 (for internal researchers). Now clearly this is not terribly meaningful without knowing how long typical analyses take. Unfortunately there’s not really any such thing as a typical analysis, and we quote for jobs on a case-by-case basis depending on individual needs.

So come and have that conversation with us – it won’t cost you anything!

The BSU last made a serious investment in hardware around 4 years ago. At that time, the sequencing revolution was starting to gather momentum. Illumina had just launched the GAIIx, promising to deliver a massive 50Gb per run. Mammoth, the machine we bought at the time, was purchased with this in mind. We had RAM to burn (or so we thought), and a couple of TBs of scratch space. 4 years on and Mammoth is showing its age. It still performs admirably, and has its niche, but the clock speed of that RAM is pathetic (we had to underclock it in order to pack so much in), and the disk space is woefully inadequate.

Monolith

Therefore, in order to keep providing the expected level of service to the increasing number of researchers undertaking sequencing studies, we need new hardware to keep up. So we have recently invested in a new system to service these demands. Monolith offers many improvements over Mammoth. It has twice the number of CPUs and RAM (and importantly these components are also much more efficient – the clock speed of the RAM being more than 3 times that of Mammoth). It also has a much more headroom in terms of disk space. All this for around a third the cost of Mammoth. I love Moore’s Law.

Cloud considerations

So, why invest in computers at all? Surely this is the age of IaaS (Infrastructure as a Service), and we should all be renting compute from Amazon et al. for all our requirements? Well, I’m still a believer in owning a heavy piece of iron. Physical hardware usually has an operating life well beyond its service contract (the machine that is serving this web page is nearly eight years old, for instance – well, apart from one or two components), and much can be done with ageing hardware (a fact of which Mammoth is ample demonstration). If we had spent the money on cloud compute over the period of the hardware’s service contract, all we would have to show for that fact would be a very large credit card bill. Also, there are limitations to the infrastructure you can rent that can’t easily be overcome. Private, commercial clouds were set up to scale websites to millions of page views, not genome analysis to billions of reads. The two problems are radically different, and require different approaches. The capacity that Monolith gives us can only be obtained right now by purchasing physical hardware.

Hopefully that capacity gives us some headroom for the next year or two, enabling us to continue to efficiently analyse the piles of interesting data being generated by the University’s researchers. No doubt this hope will be undermined by the next sequencing breakthrough (nanopore?) that has us all scurrying to catch up once again.

Just before finishing for Christmas last year I became interested in the crowd sourced effort to analyse the fungal disease currently affecting ash trees.  The disease is caused by the Chalara fraxinea fungus. The data for the project was quickly released following initial sequencing runs via GitHub. This is similar to an approach taken with sequencing data from the german E. coli O104:H4 outbreak and meant various scientists around the world could get their hands on the raw data and contribute analysis of it to the collective effort by uploading their results directly to GitHub.

So far I have contributed:

• FastQC reports of the released RNAseq reads.
• Assemblies of both the AT1 and AT2 mixed interaction transcriptome produced using Trinity, this contained reads from both the fungus and host tree, although most of the material appeared to be fungal.
• Likely coding sequences for both the Trinity derived AT1 and AT2 transcripts.
• Pfam and SUPERFAMILY HMM based domain assignments for these coding sequences, here, here, here and here.
• Detected NPP1-like necrosis inducing protein domains (aka Nep1-like proteins) found in the AT1 and AT2 samples using the HMM for the NPP1 Pfam family with HMMER.
• A multiple alignment of all AT1 and AT2 NPP1-like necrosis inducing proteins domains aligned with fungal homologues from the Helotiales order (which contains many plant pathogens) detected using an iterative Jackhmmer run (using the AT1 and AT2 sequences as a seed) over Uniprot.  Chalara fraxinea is its self part of this order so considering other necrosis inducing proteins from similar pathogenic fungi my be useful for investigating pathogenesis.

An initial publication detailing the crowd sourced effort has been published in GigaScience.  Currently I’m quite busy with a number of projects here at Newcastle but I hope to contribute more analysis to this project soon.

I’m leading a digital literacy event this afternoon for the BBSRC Doctoral Training Program PhD students from Newcastle, Durham and Liverpool Universities. The aim of the session is to provide examples and experiences of how effective use of social media can improve your output and your impact in science. For the record, I do believe this is the case (though clearly there is a balance to be struck, all things in moderation and all that), and I thought I’d use the opportunity of the workshop today to write up a list of reasons why (in no particular order). This list is largely focussed on Twitter, because that is where I spend my social media life, but it can equally apply to any of the major social networks (not Facebook though, never Facebook).

0. Your papers will be more widely read, and better cited as a result.

There is evidence (both anecdotal and systematic) that papers which receive a large amount of attention on Twitter are more highly cited. I’m not sure there’s any way having more people read your work can possibly be construed as a bad thing.

1. There are “important” people on Twitter, and they are likely to listen to you.

By “important” I could mean the Professor down the hall, or eminent researchers in your field, all the way up to Nobel Laureates. And those of them that “get” Twitter engage with their followers. There’s never been a better opportunity to make an impression on the people who shape your field of study. Take the example of Bioinformatics (admittedly a techy field, so biased in favour of good participation, but still…). The most prestigious prize in Bioinformatics is the Franklin Award, which has been handed out to 11 scientists since 2002. Of those 11 men (yes, unfortunately they are all men) 4 are active on Twitter, and still others keep blogs, or contribute to other online communities.

2. It’s a great way to keep abreast of the literature

If you follow the right group of individuals, who are interested in the same things you are, it is very likely they will share the papers that they find interesting and important. ‘Crowd-sourcing’ your literature hunt in this way can be a very useful way to make sure you don’t miss out on important papers.

3. It will help your writing skills

No really, I mean it. Crafting a tweet so that your message fits in 140 characters and is still understandable is a very definite skill, and one which will improve your writing more generally. Brevity is an extremely under-appreciated talent.

4. Hashtags collate chat and advice around topics very effectively

#phdchat is unquestionably a source of useful advice and moral support to graduate students. Other initiatives like #microtwjc (a Twitter-based journal club) are developing large communities of individuals with similar research interests.

Feel free to add any other reasons you think are valid in the comments. Below is my slidedeck from the introduction talk I’m giving this afternoon, which illustrates some of these points.

Back in February a working group proposed by Faculty Dean of Research, Michael Whitaker, met for the first time. The aim of this working group is to discuss matters relating to data management and bioinformatics that arise across the faculty. Among other ideas put forward at the meeting, Michael recommended the establishment of a Bioinformatics Interest Group, that should meet regularly in order to foster a sense of community among the faculty’s bioinformaticians, as well as sharing scientific ideas and working practise.

The Bioinformatics Support Unit was tasked with establishing this group – something we were only too happy to undertake, since it clearly fits within our mission of promoting good data analysis and handling practices across the faculty. My ideas for the group mainly revolve around an informal seminar setup, meeting every month or so to hear short talks from members of the group and to have plenty of time and space for discussion afterwards, hopefully over drinks. There will also be plenty of opportunities for alternative types of sessions, such as talks from external speakers, tutorials and even workshop sessions for sharing more complex technologies and ideas in some detail.

It has taken some time to bring everything together, but I’m delighted to be able to announce the first meeting of BIOINF-SIG (the Bioinformatics Special Interest Group), which will take place on Tuesday 12th June at 4pm in the Baddiley-Clark seminar room. At the first meeting we will be privileged to here from Dr Andrew Harrison, of the Schools of Mathematical and Biological Sciences, at the University of Essex, who will present a talk entitled “On the causes of correlations seen between probe intensities in Affymetrix GeneChips”. There’s more information about the talk on the BIOINF-SIG homepage.

Hopefully this will be the first of many fruitful meetings of this exciting new group.

Last week we ran our first training workshop for the faculty’s researchers. Over 2 days, we took them on a whistle stop tour of popular bioinformatics tools and databases, including, but not limited to:

• BLAST
• PSI-BLAST
• Jalview
• Reactome
• The Gene Ontology
• Gene Expression Omnibus
• GeneSpring GX
• Ingenuity Pathway Analysis

The full program is available on the workshop page, here on our site. We have also made the workshop handout available to download (PDF, 18MB).

We had a lot of fun preparing and running the course, and we have received some very positive feedback from the people who took part, which encourages us that this is a worthwhile activity. As a consequence I am very sure that we will be running further courses in the near future, and indeed, probably repeating this one too.

Lessons Learned

That’s not to say that everything was a complete success. We have learned that 2 day workshops should come with coffee (and probably lunch) provided, something we will endeavour to do on future courses. I also think that the second day should perhaps have been balanced more in favour of the actual microarray analysis, allowing for longer with GeneSpring (although this would mean a longer demonstration session, rather than the hands-on nature of the other sections), and with alternative tools. The first day of the course was very busy, and we covered a lot of ground. Perhaps if we’d been less ambitious with the quantity of material, we would have had more time to delve more deeply into the specific tools that the attendees found most interesting.

One of the most interesting pieces of feedback we received was someone who suggested that the sessions should be driven by a biological use case, rather than a sample set of data (possibly even drawn from the experiences of the unit, and our Faculty collaborators). I think this would certainly give a lot of the sessions more relevance for the intended audience, and it is something we will bear in mind when designing future courses.

All-in-all, running the workshop was something we enjoyed, and want to do more of, and we would welcome comments and suggestions below.