There has been a lot in the news recently about Steve Jobs fight with Pancreatic cancer. The impact on Apple has been discussed at length (BBC apple coverage, Reuters, BBC, CNN, Apple, GenomeWeb), as has the possible impact on Steve Jobs himself. I guess this is just one of the problems of being a VIP, celebrity, etc.
I do struggle a little however with the fact that this is one person amongst about 280,000 worldwide who get cancer of the Pancreas. It is a horrible disease and only about 16% of people live for more than one year after diagnosis. Research on Pancreatic Cancer is being done and we are learning more about the disease and why it might be so difficult to treat. Science recently published a paper from Professor David Tuvesons group here at CRI demonstrating how Pancreatic cancers are hypovascular and that increasing that vascalature can allow more effective treatment in mice.
Other celebrities have had cancer of course. There was a lot of news coverage when Kylie Minogue was diagnosed with Breast Cancer. At the time CRUK reported that the public undestanding of Breast Cancer was quite wrong, with most people thinking that the disease is more likely to affect people under 70. they termed this "the Kylie effect".
If Mr Jobs news worthiness as a pancreatic cancer patient increases public awareness, focuses more researchers on this cancer and results in more research £, $ or € being spent then we can hope for more advances and better treatment for all.
I cant help but think that headlines like GenomeWebs "See you later, Steve Jobs" are not the right thing to be writing about anyone with Cancer though.
Wednesday, 31 August 2011
Tuesday, 30 August 2011
The NIH view on core facilities Part 2: what does it mean for you and I
What should a core offer?
The authors of the Science TranslationalMedicine paper list four things a core needs: (i) sophisticated instruments, (ii)staff expertise in their operation, (iii) expertise in analysing the data and (iv) an ability to provide advice through consultation with users.
In my case the volume of samples being processed and the varied services being provided in my core make number (iii) difficult. There is a separate Bioinformatics core here at CRI so much of the analysis within my lab focuses on primary QC of data to make sure project data are of high quality before it is returned for secondary and tertiary analysis. This QC can be a job in itself, I rarely get time to actually analyse data and when I do I'm not far past page one for most packages. I try to make sure I understand the impact of biology on the experiment, how the analysis works in basic terms and consider how we can affect the results by changing what we do in the lab by tweaking the application.
I completely agree with the authors view that the consultation and advice provided by core labs can be as important as any actual data provided. I'd be interested to hear the view of core users on this as well. Core heads can be significantly more up-to-date on research methods and applications than users. From a sequencing stand point a PI knows they want to sequence something but it can be a long time since they did this themselves and the state of the art has changed fundamentally. Having someone local who can answer questions, suggest alternative methods and give impartial advice and feedback helps. I'd also like to think that when talking to someone in a local core people are less afraid of asking what he or she might consider "stupid" questions.
How much money is spent on core facilities?
Apparently the NIH spends about $900m a year on core facilities. The paper produces data from an analysis of 520 P30 (core infrastructure support) awards for 2010 totalling $637m. The $900m assumes a 40% underestimate of activity because of the difficulty in collecting this data. That seems like a huge margin for error to me and I'd suggest to the NIH they find a better way of recording and accounting for core activity.
It was interesting to me to find out that the NIH spent $300M of recovery act investment on shared and/or high-end instrumentation and that more confocal microscopes, mass specs or biomedical imagers were bought then next-gen sequencers. I guess this just shows how much I have my head in the sand when it comes to other research areas outside genomics. I also can't help but wonder how many more genomes we could have sequenced and does the world need that many confocal microscopes?
How are UK core facilities organised?
In the UK there are examples of small, medium and large cores. Some offer services to single groups or institutes, others multiple institutes or anyone in the UK. Some operate on a consumables only recovery model and others work towards full economic cost recovery. So the UK has every possible type of core according to the NIH models, can we say which works best in the UK?
There are examples of all these in how UK next-generation sequencing is provided with over half of instruments being in large-medium sized core-labs. There are around 30-40 next-generation sequencing labs in the UK that together have over 120 instruments (65% Illumina, 20% Roche, 15% Life Technologies). The largest funder of these is the Wellcome Trust with the Wellcome Trust Sanger Institute the largest single lab in the UK (35 instruments), however services are mainly internal to the WTSI. The MRC has decided on a distributed hub model with 4 centres (collectively nearly 30 instruments). BBSRC has funded the Genome Analysis Centre (8 instruments) to provide services to all BBSRC grant holders. And CRUK, who I work for, has invested in 2 core labs (collectively 5 instruments), CRI where the sequencing is a collaborative service across four local Institutes and LRI that primarily offers services internally. There are at least another 50 instruments in smaller UK labs. (All data from googlemap).
I would not argue that the smaller labs should be consolidated with the larger ones, nor that the UK should have one überlab but I doubt all 120 instruments are being used at maximum capacity and the total investment in instruments has been huge. I estimate a three year total for next-generation sequencing spend as likely to be over £100M. With £40M on instrument purchases alone (not including upgrades of obsolete instruments e.g. GA to HiSeq or SOLiD to 5500XL). My estimate is based on a 25% discount for instruments and consumables plus around 100 staff engaged in running or supporting the sequencing. Could the UK, or any other country achieve more "bang for its buck"?
How do you find a core?
There is not a single place to go for information. Certain communities have their own resources and the funding agencies don't put a lot of effort into this. I already suggested that Google might not be the best place to start as a search on 'DNA sequencing core facility' returns 1.2m hits!
I am happy to point out my conflict of interest before suggesting a great example is the Google map of next-gen sequencers. This has over 500 facilities on it but of course is limited to next-gen sequencing. We have been thinking about extending this to other technologies and making more distinction between academic stand alone and/or core labs versus fully commercial facilities. I'd be happy to get readers of this blogs views on that idea.
Both the ABRF and the Vermont Genetics Network host databases of core facilities. They can be more comprehensive if harder to navigate and the information is perhaps more comprehensive. Two new projects funded by NCRR are VIVO and eagle-i. Both of which are aiming to catalogue information about core facility people and resources. However most users find a core because it is in their institution or down the hall in the university. And many times they seek out a particular lab through word-of-mouth recommendation.
It pays for us as core lab managers to run our lab as efficiently and courteously as possible, always generating the highest quality data, whilst maintaining up to date applications and technologies, for as little money as possible and still keeping one eye open for that next career move. An impossible job perhaps?
Yes. But one I still happily get out of bed for every day.
The authors of the Science TranslationalMedicine paper list four things a core needs: (i) sophisticated instruments, (ii)staff expertise in their operation, (iii) expertise in analysing the data and (iv) an ability to provide advice through consultation with users.
In my case the volume of samples being processed and the varied services being provided in my core make number (iii) difficult. There is a separate Bioinformatics core here at CRI so much of the analysis within my lab focuses on primary QC of data to make sure project data are of high quality before it is returned for secondary and tertiary analysis. This QC can be a job in itself, I rarely get time to actually analyse data and when I do I'm not far past page one for most packages. I try to make sure I understand the impact of biology on the experiment, how the analysis works in basic terms and consider how we can affect the results by changing what we do in the lab by tweaking the application.
I completely agree with the authors view that the consultation and advice provided by core labs can be as important as any actual data provided. I'd be interested to hear the view of core users on this as well. Core heads can be significantly more up-to-date on research methods and applications than users. From a sequencing stand point a PI knows they want to sequence something but it can be a long time since they did this themselves and the state of the art has changed fundamentally. Having someone local who can answer questions, suggest alternative methods and give impartial advice and feedback helps. I'd also like to think that when talking to someone in a local core people are less afraid of asking what he or she might consider "stupid" questions.
How much money is spent on core facilities?
Apparently the NIH spends about $900m a year on core facilities. The paper produces data from an analysis of 520 P30 (core infrastructure support) awards for 2010 totalling $637m. The $900m assumes a 40% underestimate of activity because of the difficulty in collecting this data. That seems like a huge margin for error to me and I'd suggest to the NIH they find a better way of recording and accounting for core activity.
It was interesting to me to find out that the NIH spent $300M of recovery act investment on shared and/or high-end instrumentation and that more confocal microscopes, mass specs or biomedical imagers were bought then next-gen sequencers. I guess this just shows how much I have my head in the sand when it comes to other research areas outside genomics. I also can't help but wonder how many more genomes we could have sequenced and does the world need that many confocal microscopes?
How are UK core facilities organised?
In the UK there are examples of small, medium and large cores. Some offer services to single groups or institutes, others multiple institutes or anyone in the UK. Some operate on a consumables only recovery model and others work towards full economic cost recovery. So the UK has every possible type of core according to the NIH models, can we say which works best in the UK?
There are examples of all these in how UK next-generation sequencing is provided with over half of instruments being in large-medium sized core-labs. There are around 30-40 next-generation sequencing labs in the UK that together have over 120 instruments (65% Illumina, 20% Roche, 15% Life Technologies). The largest funder of these is the Wellcome Trust with the Wellcome Trust Sanger Institute the largest single lab in the UK (35 instruments), however services are mainly internal to the WTSI. The MRC has decided on a distributed hub model with 4 centres (collectively nearly 30 instruments). BBSRC has funded the Genome Analysis Centre (8 instruments) to provide services to all BBSRC grant holders. And CRUK, who I work for, has invested in 2 core labs (collectively 5 instruments), CRI where the sequencing is a collaborative service across four local Institutes and LRI that primarily offers services internally. There are at least another 50 instruments in smaller UK labs. (All data from googlemap).
I would not argue that the smaller labs should be consolidated with the larger ones, nor that the UK should have one überlab but I doubt all 120 instruments are being used at maximum capacity and the total investment in instruments has been huge. I estimate a three year total for next-generation sequencing spend as likely to be over £100M. With £40M on instrument purchases alone (not including upgrades of obsolete instruments e.g. GA to HiSeq or SOLiD to 5500XL). My estimate is based on a 25% discount for instruments and consumables plus around 100 staff engaged in running or supporting the sequencing. Could the UK, or any other country achieve more "bang for its buck"?
How do you find a core?
There is not a single place to go for information. Certain communities have their own resources and the funding agencies don't put a lot of effort into this. I already suggested that Google might not be the best place to start as a search on 'DNA sequencing core facility' returns 1.2m hits!
I am happy to point out my conflict of interest before suggesting a great example is the Google map of next-gen sequencers. This has over 500 facilities on it but of course is limited to next-gen sequencing. We have been thinking about extending this to other technologies and making more distinction between academic stand alone and/or core labs versus fully commercial facilities. I'd be happy to get readers of this blogs views on that idea.
Both the ABRF and the Vermont Genetics Network host databases of core facilities. They can be more comprehensive if harder to navigate and the information is perhaps more comprehensive. Two new projects funded by NCRR are VIVO and eagle-i. Both of which are aiming to catalogue information about core facility people and resources. However most users find a core because it is in their institution or down the hall in the university. And many times they seek out a particular lab through word-of-mouth recommendation.
It pays for us as core lab managers to run our lab as efficiently and courteously as possible, always generating the highest quality data, whilst maintaining up to date applications and technologies, for as little money as possible and still keeping one eye open for that next career move. An impossible job perhaps?
Yes. But one I still happily get out of bed for every day.
The NIH view on core facilities
A recent commentary article in Science TranslationalMedicine on core facilities is probably of interest to those other core lab directors reading my blog. I wanted to look at some of the points they raise and give my thoughts as a core facility director.
Gregory Faber from NIH and Linda Weiss from NCI have written a very nice piece on the need for efficient and organised core facilities. They outline what has been going on at the NIH to "strengthen core facilities". And discuss four focus areas; (i) information underload - making available better quality information about cores, (ii) paving the core career path - developing career paths and training for core heads, (iii) government regulation - improving understanding of regulatory requirements and (iiv) core facility fusion - aiding core centralisation and consolidation.
(i) Information underload: it needs to be easier to find information about core facilities, where they are, what services they offer etc. Of course this sounds simple, but a search on Google for 'core facility' returns 7m results, whilst the more specific 'DNA sequencing core facility' still returns 1.2m!
There are two current databases and two new initiatives mentioned in the paper. Databases of core facilities are available from; ABRF and the Vermont Genetics Network . The new projects funded by NCRR are VIVO and eagle-i. I'd like to take the chance to mention the Google map of next-gen sequencers . This has 500 facilities on it and has not cost the American taxpayer a cent. I'd happily apply for an NIH grant to make this available under their umbrella.
(ii) Paving the core career path: Core facility heads need to receive better training in the business aspects of running an SME. There is more and more formal training for new group leaders but a core director has to work in a very different setting. There is also often no obvious career path for Core staff and they are often employed on soft money. Improvements in both of these would help to stabilise core staff.
(iii) Government regulation: Cores may have to follow government regulations on cross-charging. There are three main funding schemes in cores; reagents only, reagents + service contracts (with or without some staff time), or full economic cost recovery. It is not clear which model offers the best value for money and each can have consequences on core demands. For instance many core directors will have been faced with the need to cover costs on low demand services which results in costs increasing to a level where those services are effectively priced out of the market. This is fine from a business perspective but only if the financial aspects are being considered, there can be other important factors in keeping a service local even if demand is low. This needs to be a local decision so the local stakeholders may need to pay more.
(iv) Core facility fusion: There is little evidence to determine whether large centralised cores offer better value than small decentralised ones. The authors discuss briefly the pros and cons of different management structures, of centralisation versus distribution and the requirement of users to have a core that understand their needs. Of particular interest to the US readers is probably the discussion on consolidation of cores where the research population is low and the IDeA core labs.
Whilst the paper is written from the perspective of current funding levels and a need to save research $, £ or €, much of that discussed has probably been thought about by core facilities or their users for the past 15-20 years.
They state that access to scientific core facilities, with sophisticated instruments and experienced staff has become essential for much clinical and translational research. I'm sure anyone who has had access to a high quality core would argue this for any area of scientific research. A good core should make science easier, allowing research staff to move quickly between different and difficult techniques to get useful and robust data. As an aside I'd recommend you take a look at "What kind of core areyou"?
My summary:
The main discussion point of the paper is that cores should be run as efficiently as possible, I don't think anyone would argue with that suggestion. This requires that cores monitor and record their efficiency and have external benchmarks to compare to. I am not aware of any external benchmarking data for this purpose; perhaps we should start publishing some?
I'd add one more thing into the core facility fusion space, or even on its own; Lab management systems. LIMs are used in many vcore facilities to track samples and data generated from them. Considering the investment in current genomics technologies there is a real lack of joined-up thinking on LIMs for this. Most labs use their own in-house developed systems. Some buy commercially and a few try to instil academically developed LIMs. I think the NIH could do well to invest a few research$ into LIMs developmetnt for common technolgies.
Many cores have grown over several years and this growth may not always have been planned with ruthless efficiency. Cores can also be duplicated in a local region for multitude reasons. Maximising efficiency and minimising duplication are obvious ways to save money by having fewer, probably larger cores. However many institutes or group leaders will want to have a duplicate facility and if the funding agencies are not more ruthless in finding examples of and rejecting that duplication then it will continue.
There appears to be a cycle in core facilities similar to the mergers and breakups seen in the commercial sector. Sometimes small cores located close to research groups are in favour, a few years later and big centralised cores appear to be "de rigeur". Normally each country and technology appears to be at different parts of the cycle. The recent economic collapse seems to have pushed funding agencies to all think about saving money, and core facilities are an option along with everything else.
From my experience the medium sized collaborative core, with more than one major stakeholder, is the one that works best. Having several large investors with a real interest in the core succeeding has enabled high quality investment in equipment and staff. It has allowed us to reinvest as technology moves on. It has also provided a larger pool of users, bringing interesting science into the core and making sure we run as close to actual capacity as possible.
Gregory Faber from NIH and Linda Weiss from NCI have written a very nice piece on the need for efficient and organised core facilities. They outline what has been going on at the NIH to "strengthen core facilities". And discuss four focus areas; (i) information underload - making available better quality information about cores, (ii) paving the core career path - developing career paths and training for core heads, (iii) government regulation - improving understanding of regulatory requirements and (iiv) core facility fusion - aiding core centralisation and consolidation.
(i) Information underload: it needs to be easier to find information about core facilities, where they are, what services they offer etc. Of course this sounds simple, but a search on Google for 'core facility' returns 7m results, whilst the more specific 'DNA sequencing core facility' still returns 1.2m!
There are two current databases and two new initiatives mentioned in the paper. Databases of core facilities are available from; ABRF and the Vermont Genetics Network . The new projects funded by NCRR are VIVO and eagle-i. I'd like to take the chance to mention the Google map of next-gen sequencers . This has 500 facilities on it and has not cost the American taxpayer a cent. I'd happily apply for an NIH grant to make this available under their umbrella.
(ii) Paving the core career path: Core facility heads need to receive better training in the business aspects of running an SME. There is more and more formal training for new group leaders but a core director has to work in a very different setting. There is also often no obvious career path for Core staff and they are often employed on soft money. Improvements in both of these would help to stabilise core staff.
(iii) Government regulation: Cores may have to follow government regulations on cross-charging. There are three main funding schemes in cores; reagents only, reagents + service contracts (with or without some staff time), or full economic cost recovery. It is not clear which model offers the best value for money and each can have consequences on core demands. For instance many core directors will have been faced with the need to cover costs on low demand services which results in costs increasing to a level where those services are effectively priced out of the market. This is fine from a business perspective but only if the financial aspects are being considered, there can be other important factors in keeping a service local even if demand is low. This needs to be a local decision so the local stakeholders may need to pay more.
(iv) Core facility fusion: There is little evidence to determine whether large centralised cores offer better value than small decentralised ones. The authors discuss briefly the pros and cons of different management structures, of centralisation versus distribution and the requirement of users to have a core that understand their needs. Of particular interest to the US readers is probably the discussion on consolidation of cores where the research population is low and the IDeA core labs.
Whilst the paper is written from the perspective of current funding levels and a need to save research $, £ or €, much of that discussed has probably been thought about by core facilities or their users for the past 15-20 years.
They state that access to scientific core facilities, with sophisticated instruments and experienced staff has become essential for much clinical and translational research. I'm sure anyone who has had access to a high quality core would argue this for any area of scientific research. A good core should make science easier, allowing research staff to move quickly between different and difficult techniques to get useful and robust data. As an aside I'd recommend you take a look at "What kind of core areyou"?
My summary:
The main discussion point of the paper is that cores should be run as efficiently as possible, I don't think anyone would argue with that suggestion. This requires that cores monitor and record their efficiency and have external benchmarks to compare to. I am not aware of any external benchmarking data for this purpose; perhaps we should start publishing some?
I'd add one more thing into the core facility fusion space, or even on its own; Lab management systems. LIMs are used in many vcore facilities to track samples and data generated from them. Considering the investment in current genomics technologies there is a real lack of joined-up thinking on LIMs for this. Most labs use their own in-house developed systems. Some buy commercially and a few try to instil academically developed LIMs. I think the NIH could do well to invest a few research$ into LIMs developmetnt for common technolgies.
Many cores have grown over several years and this growth may not always have been planned with ruthless efficiency. Cores can also be duplicated in a local region for multitude reasons. Maximising efficiency and minimising duplication are obvious ways to save money by having fewer, probably larger cores. However many institutes or group leaders will want to have a duplicate facility and if the funding agencies are not more ruthless in finding examples of and rejecting that duplication then it will continue.
There appears to be a cycle in core facilities similar to the mergers and breakups seen in the commercial sector. Sometimes small cores located close to research groups are in favour, a few years later and big centralised cores appear to be "de rigeur". Normally each country and technology appears to be at different parts of the cycle. The recent economic collapse seems to have pushed funding agencies to all think about saving money, and core facilities are an option along with everything else.
From my experience the medium sized collaborative core, with more than one major stakeholder, is the one that works best. Having several large investors with a real interest in the core succeeding has enabled high quality investment in equipment and staff. It has allowed us to reinvest as technology moves on. It has also provided a larger pool of users, bringing interesting science into the core and making sure we run as close to actual capacity as possible.
Friday, 22 July 2011
Ion Torrent has the "Law" on their side
Bang went the starter gun in August 2010 when LifeTechnologies announced the purchase of Ion Torrent for $375M (plus another $350M if certain milestones are reached).
Yesterday in Nature Life Technologies and Ion Torrent published the genome of Gordon Moore of “Moore’s law” fame, plus 3 bacterial genomes. I’d like to know how much Gordon thought about DNA sequencing before his law was quoted in almost every next-gen presentation over the last four or five years? Let alone what went through his head when approached by Ion and LifeTech! The Moore genome required about 1000 Ion chips or a bilion detector wells. In the supplementary information for the paper Ion sugest a route to a 1B well chip (see later on in this post) which would be pretty awsome.
Over at Genetic Future there is a nice commentary of the Human Genome results. Daniel MacArthur states pretty categorically that this is nowhere near a cost effective way to sequences humans “yet”. I posted on SEQanswers in February that Ion could get to HiSeq output by 2013 after reading an interview with Jonathan Rothberg, inwhich he said to expect a 10-fold improvement from Ion every six months. It looks like they have achieved so far, but will they keep this up to get to 100Gb by the middle of 2013?
Dan also makes a very strong argument against the papers claims on quality and validation with SOLiD. Dan’s comments on the low coverage are very persuasive. I’d excuse Life Tech and Ion for the 10x Moore genome, but there can be little excuse for Life Tech on a 15x SOLiD genome. They could have very easily brought this closer to the standard of 30-50x coverage. I hope it is obvious to everyone reading the paper that Ion and SOLiD come from the same company and that there is likely a vested interest in saying how great both technologies are.
Dan thought Life Technologies may have made a mistake putting the Human genome into the paper. I really hope that without it this work would not have made it into Nature! A genome today even on a new sequencing technology just does not feel like it should pass the bar of entry to Nature. It’s a tough club to get in to!
Nature News makes a lot of the fact that a bacterial genome can be sequenced in two hours. They seem to ignore library prep entirely and even with the new automated ePCR this is probabaly a days work at least. Illumina's purchase of Epicentre gives tehm the Nextera technology and it really is possible to sequence a genome in an eight hour day. If you can get one delivered of course.
Nature News makes a lot of the fact that a bacterial genome can be sequenced in two hours. They seem to ignore library prep entirely and even with the new automated ePCR this is probabaly a days work at least. Illumina's purchase of Epicentre gives tehm the Nextera technology and it really is possible to sequence a genome in an eight hour day. If you can get one delivered of course.
One of the interesting things to me was too look at what developments we might deduce in terms of throughput. In the paper the authors state read lengths of over 200bp and that only 20-40% of detector wells generate mappable reads. Moving past 100bp reads and increasing %mappable reads to closer to 100 will make a massive difference to the ultimate output. However I do not know enough about the technical challenges Life may face here. This is almost certainly the kind of development that will get Ion Torrent the further $350 from Life.
In the supplementary figures for the Nature paper Ion demonstrate 1.3um wells on a 1.68 pitch array allowing up to 165M detector wells. They say that this could increase to 1B but it sounds like a tough step to take. At 1B wells and 30bp then Ion is giving us the same yield as a v3 HiSeq flowcell today. How long it might take to get there is another matter. There are 20 supplemental figures. Number 8 shows the instrument and points out the major features, one of which is the accompanying iPod and it's dock!
In the supplementary figures for the Nature paper Ion demonstrate 1.3um wells on a 1.68 pitch array allowing up to 165M detector wells. They say that this could increase to 1B but it sounds like a tough step to take. At 1B wells and 30bp then Ion is giving us the same yield as a v3 HiSeq flowcell today. How long it might take to get there is another matter. There are 20 supplemental figures. Number 8 shows the instrument and points out the major features, one of which is the accompanying iPod and it's dock!
One of the challenges mentioned in discussions I have had with users of the Ion Torrent is that the current emulsion PCR is limiting the size of amplicon that can be generated on the acrylamide beads. If the Ion technology is going to get to 400bp like 454 or even to 1000bp then a larger PCRPCR paper that describes how size of bead affects amplicon length I’d be grateful. So far I have looked at "SNP genotyping by multiplexed solid-phaseamplification and fluorescent minisequencing" and "Product length, dye choice, anddetection chemistry in the bead-emulsion amplification of millions of single DNAmolecules in parallel".
It is going to be an interesting to see how Ion respond to Roche’s entry into semi-conductor sequencing. If one of them gets a system that can actually scale according to Moore’s law then Illumina will need to squeeze more out of SBS or possibly Oxford nanopore?
Wednesday, 20 July 2011
How good are the ENCODE RNA-Seq guidelines?
The ENCODE consortium released its first set of data-standards guidelines and interestingly they are for RNA-Seq. ChIP-Seq guidelines will follow later which is a little surprising considering almost all the ENCODE data so far is ChIP-Seq (see below). In some ways I’d have preferred to see the ChIP-Seq document first. As ChIP-Seq is pretty mature it would have been clear how much ENCODE had taken into account the different lab and analytical methods and distilled what was important in an experiment.
There is a bit of a hole in the guidelines from my point of view as there is no comparison or recommendation on methods. When I first looked at the site this is exactly the information I was hoping to get. There is none, zip, zilch! I was also surprised that there are no references in these guidelines. I think this is a significant shortcoming from the ENCODE consortium and one that needs to be fixed. I would very much hope that there are protocol recommendations for the more mature ChIP-Seq methods when those guidelines are written.
A lot of the guideline recommendations come from experience of microarrays. This document is nowhere near as comprehensive as MIAME but I think it will be easier for users to adopt because of this. The Metadata section is a nice concise list of information to collect for an experiment, RNA-Seq or otherwise. I'd encourage anyone doing a sequencing or array experiment to read this list and think about other factors they might need to collect in their own experiments.
Whilst these guidelines are a reasonable start and outline many of the issues RNA-Seq users need to consider, they fall a long way short of being truly useful to someone considering where to start with an RNA-Seq experiment.
Whilst these guidelines are a reasonable start and outline many of the issues RNA-Seq users need to consider, they fall a long way short of being truly useful to someone considering where to start with an RNA-Seq experiment.
ENCODE data so far: About 20 labs have submitted data to ENCODE according to their data summary. When I looked there was no ChIP-Chip data in the summary; almost 85% of the data is from sequencing experiments with 63% ChIP-Seq, 8% RNA-Seq, 7%, DNAse-Seq, 4% Methyl-Seq and 2% FAIRE-Seq.
The Guidelines
Methods: RNA-Seq Methods mentioned include. transcript quantification, differential gene expression, discovery and splicing analysis. They don’t mention allele specific expression. Many types of input can be used in these methods, Total RNA (including miRNA of course), single cell RNA, smallRNA, polyA+ RNA, polysomal RNA, etc, etc, etc. The authors do state how immature RNA-Seq is and that the applications are evolving incredibly rapidly in almost every part of an experiment; sample prep, sequencing and analysis. They say they don’t aim to cover every possible application but instead focus on the major ones and also provide recommendations for providing meta-data, something too many scientists still don’t collect before and during an experiment, let alone submit with the data for analysis.
Metadata: recommendations include the usual suspects. For Cell lines; accession number, passage number, culture conditions, STR and Mycoplasma test results. For tissue the source and genotype if this is an animal, sample collection and processing methods, cellularity scores. And for the final RNA the method used for extraction and QC results (bioanalyser database anyone?)
Replication: They say that RNA-Seq experiments should be replicated (biological rather than technical) although ENCODE recommend a minimum of two replicates, which is very low. I defy anyone to find a statistician involved in microarray experiments that would settle for anything less than three and probably four replicates today. However they do give a get out clause for those who can’t replicate by stating “unless there is a compelling reason why this is impractical or wasteful”. An interesting point is that these guidelines suggest an RPKM correlation of at least 0.92 is required otherwise an experiment should be repeated or explained. I would have thought anyone publishing their experiments would already be explaining this and that reviewers would pick up on such poor correlations.
Read-depth: This is one of the hottest topics for RNA-Seq. It makes a massive difference to the final cost of the experiment and is a major determinant in the “microarrays vs sequencing” thought process. ENCODE suggest around 30M paired end reads for differential gene expression, however Illumina are suggesting you can use as few as 2M reads per sample today if you want the same sensitivity as Affy arrays. That’s a 15 fold difference and I suspect this will be revised in the next version of the guidelines. They do say that other methods will require more reads, up to 200M.
ENCODE aim to update this document annually, I am sure many will be encouraged by this as a useful endeavor. What about a step further with an open access Genomic journal that only covers annual reviews of methods, compares the variations and makes recommendations for a consensus protocol?
“Genome Methods Reviews” perhaps?
Friday, 15 July 2011
Understanding mutation nomenclature
I have recently been analysing some next-gen sequencing data for mutation detection. I realised pretty early on how long ago it was I had the opportunity to analyse some data of my own, as my day job is the generation of someone else's. I have been scanning through lots of data, COSMIC and many publications and thought I had better get up to speed on the naming conventions for different mutations and polymorphisms. Whilst doing so I thought I'd write a little primer to look back on and share with others.
First off I'd recommend some resources and references: Almost everything comes from these sources and the website is really comprehensive.
1. Antonarakis et al: Recommendations for a nomenclature system for Human gene mutations. 1998; Human Mutation 11:1-3. This was written before the Human Genome project was completed and a nice easy downloadable reference sequence from UCSC or Ensembl was not really conceivable. Looking back at papers like this reminds me how much we seem to take for granted in our day-to-day science!
2. den Dunnen et al. Mutation nomenclature extensions and suggestions to describe complex mutations: a discussion. 2000; Human Mutation 15:7-12 This paper presented an updated set of recommendations to allow comprehensive reporting of more complex mutations, and as such has been very useful in Cancer genomics.
3. http://www.hgvs.org/mutnomen/recs.html: the Human Genome Variation Society website as probably the primary resource for mutation nomenclature.
How to report mutations:
The basic structure of a nucleotide change is as follows:
{Genomic locus or reference accession}{gDNA or cDNA}{nucleotide interval}{reference nucleotide}{type of change}{actual nucleotide}
e.g. NM_000546g.76A>T, where nucleotide 76 in TP53 has been changed from A to T.
Use the accession number for the genomic reference sequence from RefSeq (e.g. NM_000546 for TP53 from HGNC). Nucleotide numbers are preceded by a "g.", "c.", "m.", "r.", "p." denoting genomic, cDNA, mitochondrial, RNA or protein sequence respectively. For g, c, and r the A of the ATG start codon is nucleotide +1, the nucleotide 5' to +1 is denoted -1 and there is no nucleotide 0. If there is more than one mutation in a single allele these are listed together inside [brackets]. Nucleotides are represented in capitals for gDNA (A,C,G,T) and in lowercase for cDNA (a,c,g,u), amino acids are represented by their one letter IUPAC codes (see the bottom of this post).
Different types of mutation:
Substitutions: c.76A>T
Deletions: c.76del or c.76_78delACT
Duplications: c.76dup or c.76_78dupACT
Insertions: e.g. c.76insG
Inversions: c.76_83inv8
Conversion: c.76_355conNM_004006.1:c.155_355
Indels: e.g. c76_83delinsTG
Translocations: t(X;4)(p21.2;q35)
Complex: see details below.
What about big changes? It would be impractical to list 100s or 1000s of bases using this nomenclature. Large changes are denoted only by the number of bases changed (e.g. c76ins1786), however an accession number for a sequence file should also be provide.
When is an insertion a duplication, etc, etc, etc? If you take the example ACTTTGTGCC in the reference and ACTTTGTGGCC in tour sample you could have a duplication of G at position 8 or an insertion of G between positions 8&9, c.8dupG or c.8_9insG. Duplicating insertions are described a duplications as this is a simpler and clearer description. Of course it is not clear whether the additional base is a true duplication resulting from polymerase slippage or is actually an insertion of a new but identical base from outside the reference sequence.
What happens downstream of the first mutation? If a duplication or deletion change in your sequence is followed by a subsequent change I am not clear how the following changes are presented. Now every base will be wrong compared to the reference, how does this complexity get resolved? (sorry but I need to add to this later, probably when I confront such a problem myself).
What happens when the reference changes? An interesting point and one that I had not considered too deeply was what do you use as the reference sequence and how do you deal with changes in it. The Human genome has a pretty good reference and this is considered to be the wild-type allele. However the reference is being updated with new information and groups or users can request that the reference allele is changed when it is shown that a variant is actually the more common allele. Obviously this has an impact on what is reported in papers, as such it is always helpful to indicate which genome build has been used. The simple answer is to always reference the genome build you used in your paper or report.
IUPAC codes: These are handy when referencing mutations so I thought I'd include the single letter codes for nucleotides and amino acids as I always forget these and there is a good chance I will remember I wrote this blog!
Symbols:
A Adenine
C Cytosine
G Guanine
T Thymine
R G or A puRine
Y T or C pYrimidine
M A or C aMino
K G or T Keto
S G or C Strong interaction (3 H bonds)
W A or T Weak interaction (2 H bonds)
H A or C or T "not-G, H follows G in the alphabet"
B G or T or C "not-A, B follows A"
V G or C or A "not-T (not-U), V follows U"
D G or A or T "not-C, D follows C"
N G or A or T or C aNy
Complementary symbols:
Symbol A C G T B D H K M S V W N
Complement T G C A V H D M K S*B W*N*
First off I'd recommend some resources and references: Almost everything comes from these sources and the website is really comprehensive.
1. Antonarakis et al: Recommendations for a nomenclature system for Human gene mutations. 1998; Human Mutation 11:1-3. This was written before the Human Genome project was completed and a nice easy downloadable reference sequence from UCSC or Ensembl was not really conceivable. Looking back at papers like this reminds me how much we seem to take for granted in our day-to-day science!
2. den Dunnen et al. Mutation nomenclature extensions and suggestions to describe complex mutations: a discussion. 2000; Human Mutation 15:7-12 This paper presented an updated set of recommendations to allow comprehensive reporting of more complex mutations, and as such has been very useful in Cancer genomics.
3. http://www.hgvs.org/mutnomen/recs.html: the Human Genome Variation Society website as probably the primary resource for mutation nomenclature.
How to report mutations:
The basic structure of a nucleotide change is as follows:
{Genomic locus or reference accession}{gDNA or cDNA}{nucleotide interval}{reference nucleotide}{type of change}{actual nucleotide}
e.g. NM_000546g.76A>T, where nucleotide 76 in TP53 has been changed from A to T.
Use the accession number for the genomic reference sequence from RefSeq (e.g. NM_000546 for TP53 from HGNC). Nucleotide numbers are preceded by a "g.", "c.", "m.", "r.", "p." denoting genomic, cDNA, mitochondrial, RNA or protein sequence respectively. For g, c, and r the A of the ATG start codon is nucleotide +1, the nucleotide 5' to +1 is denoted -1 and there is no nucleotide 0. If there is more than one mutation in a single allele these are listed together inside [brackets]. Nucleotides are represented in capitals for gDNA (A,C,G,T) and in lowercase for cDNA (a,c,g,u), amino acids are represented by their one letter IUPAC codes (see the bottom of this post).
Different types of mutation:
Substitutions: c.76A>T
Deletions: c.76del or c.76_78delACT
Duplications: c.76dup or c.76_78dupACT
Insertions: e.g. c.76insG
Inversions: c.76_83inv8
Conversion: c.76_355conNM_004006.1:c.155_355
Indels: e.g. c76_83delinsTG
Translocations: t(X;4)(p21.2;q35)
Complex: see details below.
- Substitutions: ">" indicates a substitution at DNA level where one nucleotide has been replaced by another (e.g. c.76A>T, where nucleotide 76 in the reference has been changed from A to T).
- Deletions: "del" indicates a deletion in the reference sequence where at least one nucleotide is removed (e.g. c.76del or c.76delA, where nucleotide 76, an A has been deleted and c.76_78del or c.76_78delACT where the three nucleotides at positions 76,77&78, ACT have been deleted. The bases deleted are not absolutely required in the description but can be helpful.)
- Duplications: "dup" indicates a duplication of the reference sequence (like c.76dup or c.76dupA where nucleotide 76, an A has been duplicated and c.76_78dup or c.76_78dupACT where the three nucleotides at positions 76,77&78, ACT have been duplicated.
- Insertions: "ins" indicates an insertion in the reference sequence (e.g. c.76insG where a G has been inserted between nucleotides 76 and 77).
- Inversions: "inv" indicates an inversion of the reference sequence between the bases reported (e.g. c.76_83inv or c.76_83inv8 where the 8 nucleotides between positions 78 and 83 have been inverted with respect to the reference.)
- Conversion: "con" indicates a conversion of a region of the reference genome to another region. These can be complex events involving highly homologous sequences in the genome and thus may also include multiple changes in the converted sequence (e.g. c.76_355conNM_004006.1:c.155_355 where nucleotides 76 to 355 of the reference have been converted to nucleotides 155 to 355 from the sequence in GenBank accession NM_004006.1).
- Indels: These genomic events are quite common but the recommended nomenclature requires that they are reported as DelIns (not quite so catchy!) for clarity (e.g. c76_83delinsTG where the 8 nucleotides between positions 76&83 have been deleted and a TG sequence has been inserted in their place).
- Translocations: "t" indicates a translocation between genomic loci (e.g. t(X;4)(p21.2;q35)) where a translocation has occurred between chromosome bands Xp21.2 and 4q34. A translocation should be reported in reference to a sequence accession number where possible.
- Complex: similarly to big changes (see below) it is often easier to report a complex change in reference to a sequence accession number with a brief textual description.
- Other identifiers: The underscore "_" indicates that a range of bases have been affected (see above for numerous examples), square brackets indicate an allele "[]" (e.g. c[76A>T]) and round brackets indicate that the exact position of the change is unknown "()" and the range of uncertainty is reported using the underscore (e.g. c.(67_70)insG).
What about big changes? It would be impractical to list 100s or 1000s of bases using this nomenclature. Large changes are denoted only by the number of bases changed (e.g. c76ins1786), however an accession number for a sequence file should also be provide.
When is an insertion a duplication, etc, etc, etc? If you take the example ACTTTGTGCC in the reference and ACTTTGTGGCC in tour sample you could have a duplication of G at position 8 or an insertion of G between positions 8&9, c.8dupG or c.8_9insG. Duplicating insertions are described a duplications as this is a simpler and clearer description. Of course it is not clear whether the additional base is a true duplication resulting from polymerase slippage or is actually an insertion of a new but identical base from outside the reference sequence.
What happens downstream of the first mutation? If a duplication or deletion change in your sequence is followed by a subsequent change I am not clear how the following changes are presented. Now every base will be wrong compared to the reference, how does this complexity get resolved? (sorry but I need to add to this later, probably when I confront such a problem myself).
What happens when the reference changes? An interesting point and one that I had not considered too deeply was what do you use as the reference sequence and how do you deal with changes in it. The Human genome has a pretty good reference and this is considered to be the wild-type allele. However the reference is being updated with new information and groups or users can request that the reference allele is changed when it is shown that a variant is actually the more common allele. Obviously this has an impact on what is reported in papers, as such it is always helpful to indicate which genome build has been used. The simple answer is to always reference the genome build you used in your paper or report.
IUPAC codes: These are handy when referencing mutations so I thought I'd include the single letter codes for nucleotides and amino acids as I always forget these and there is a good chance I will remember I wrote this blog!
Symbols:
A Adenine
C Cytosine
G Guanine
T Thymine
R G or A puRine
Y T or C pYrimidine
M A or C aMino
K G or T Keto
S G or C Strong interaction (3 H bonds)
W A or T Weak interaction (2 H bonds)
H A or C or T "not-G, H follows G in the alphabet"
B G or T or C "not-A, B follows A"
V G or C or A "not-T (not-U), V follows U"
D G or A or T "not-C, D follows C"
N G or A or T or C aNy
Complementary symbols:
Symbol A C G T B D H K M S V W N
Complement T G C A V H D M K S*B W*N*
Saturday, 25 June 2011
What sort of user are you?
Back in April Tales of the Genomic Repairman discussed five core facility stereotypes; Core of ill-repute, High $ Hooka core, the Waiting by the phone for the core to call core, the High maintenance core and the Easy core next door. I hope my users see the core I run as an easy core next door.
I thought I’d follow up after a conversation around Genomic Repairmans blog at a recent Illumina user meeting in Chantilly where six core heads were on the same table at dinner. We all agreed that those stereoptypes exist but the same goes for users. Anyway, here is what we came up with...
The “the deadline is always tomorrow” user always professes that their experiment needs to happen now, the data is either needed for a paper (Nature, Cell or Science of course) or a looming grant deadline. If the core can’t deliver then this guy’s career is over. You meet them six weeks later in the pub after work and ask if the paper was accepted and they say, “sorry, I’ve not had time to look at the data yet”! We want to help when we can and my lab can run an array project in three days if samples are ready to roll. But whilst we all know priorities get changed you can't pull this too many times. Ever heard of the boy who cried wolf?
The “how can I do it cheaper” user always wants to cut corners to bring the cost of the experiment down. If you say four replicates they say “three”, when you say three they say “two, you can do stats on two can’t you?” Their experiments never quite seem to generate results that can be validated.
The “I didn’t quite follow the protocol” user brings their samples along but casually let you know that they had to skip a clean up or amplification step to get the samples in before heading off for the weekend. You can bet they’ll be disappointed when the job does not work and they are still asked to pay. This user is often unhappy with the quality of the work from the core.
The “I want to use this method that was just published last week” user can often lead to an exciting new application in the core. However this kind of user can also come back the week after and say forget about the last method, this ones really great. It can be difficult to know when they are coming in with the next big thing rather than a fad. This user is enthusiastic but can take up a lot of time, however most cores relish the conversations and the opportunity to work on new ideas.
The " " silent user. Most of us round the table thought many users were too quiet. Whilst they seem happy with services offered, with the quality and turnaround of data, their feedback is limited. We want these users to talk to us more. Tell us what they like and don’t like. They have the opportunity to shape how our cores develop with their comments.
The “thanks a lot” user. This user always says thanks when they get their results. Even better, they always acknowledge the work the core did in the paper and sometimes include core staff as authors if it is warranted. The core is always happy to see this person back again and will always try to give that little extra. Service for this guy comes with a smile.
A last comment: Users of core facilities should speak with the staff and mangers. If you have a Core that’s not so easy going then talk to them about it. Constructive criticism should be taken on board and who knows soon your Core of ill-repute could soon be as easy going as you’d always hoped for.
I thought I’d follow up after a conversation around Genomic Repairmans blog at a recent Illumina user meeting in Chantilly where six core heads were on the same table at dinner. We all agreed that those stereoptypes exist but the same goes for users. Anyway, here is what we came up with...
The “the deadline is always tomorrow” user always professes that their experiment needs to happen now, the data is either needed for a paper (Nature, Cell or Science of course) or a looming grant deadline. If the core can’t deliver then this guy’s career is over. You meet them six weeks later in the pub after work and ask if the paper was accepted and they say, “sorry, I’ve not had time to look at the data yet”! We want to help when we can and my lab can run an array project in three days if samples are ready to roll. But whilst we all know priorities get changed you can't pull this too many times. Ever heard of the boy who cried wolf?
The “how can I do it cheaper” user always wants to cut corners to bring the cost of the experiment down. If you say four replicates they say “three”, when you say three they say “two, you can do stats on two can’t you?” Their experiments never quite seem to generate results that can be validated.
The “I didn’t quite follow the protocol” user brings their samples along but casually let you know that they had to skip a clean up or amplification step to get the samples in before heading off for the weekend. You can bet they’ll be disappointed when the job does not work and they are still asked to pay. This user is often unhappy with the quality of the work from the core.
The “I want to use this method that was just published last week” user can often lead to an exciting new application in the core. However this kind of user can also come back the week after and say forget about the last method, this ones really great. It can be difficult to know when they are coming in with the next big thing rather than a fad. This user is enthusiastic but can take up a lot of time, however most cores relish the conversations and the opportunity to work on new ideas.
The " " silent user. Most of us round the table thought many users were too quiet. Whilst they seem happy with services offered, with the quality and turnaround of data, their feedback is limited. We want these users to talk to us more. Tell us what they like and don’t like. They have the opportunity to shape how our cores develop with their comments.
The “thanks a lot” user. This user always says thanks when they get their results. Even better, they always acknowledge the work the core did in the paper and sometimes include core staff as authors if it is warranted. The core is always happy to see this person back again and will always try to give that little extra. Service for this guy comes with a smile.
A last comment: Users of core facilities should speak with the staff and mangers. If you have a Core that’s not so easy going then talk to them about it. Constructive criticism should be taken on board and who knows soon your Core of ill-repute could soon be as easy going as you’d always hoped for.
Thursday, 23 June 2011
MiSeq vs Ion: How a little bug got involved in a big battle
How a little bug got involved in a big battle: MiSeq vs Ion
There has been a lot said about the recent sequencing of E coli from the recent outbreak in Germany. Over five isolates have been sequenced on almost every sequencing platform, HiSeq, 454, Ion and MiSeq. Interestingly I am not aware of a SOLiD or a Sanger genome. I’d recommend Genomewebs coverage as a good starter if you’re interested in finding out more.
Just this week Illumina made available a slide deck and data from their analysis of E coli K12MG1655 sequenced on HiSeq (PE100) and MiSeq (PE150).
The first 8 slides are the HiSeq MiSeq comparison:
Throughput seems to have gone up to 1.5Gb, which is a 50% increase over the initial specs so growth seems to be as fast on MiSeq as it has been on GA and HiSeq platofmrs. Albeit with just one data point so far. And there is still a,long way to go before it gets to 25Gb, see my first blog.
Libraries for the comparison were made using Tru Seq and not the Nextera kits from the recent Epicentre purchase which I was a little surprised about. Ot would have been great to see a multiplexed run on the two platforms for a TruSeq and Nextera comparison in the same data set.
Essentialy MiSeq outperforms HiSeq on quality a tiny bit. Other than that the datasets are pretty much the same n all respects. The HiSeq run has the characteristic intensity fluctuation at about 75bp where laser power is adjusted mid-run. Both runs have a stepped prfile in Men Qscore which I guess is a function of alignment getting better till about 20bp then declining with read quality. In this presentation Illumina do not show the Mean Qscore at 150bp for MiSeq.
Illumina sub samples the HiSeq run for a de novo assembly comparison and the result were strickingly similar in all respects other than MiSeq gave 11 where HiSeq gave 12 contigs. I am not an assembly wiz so can’t think why this would be the case nor whether it would matter a great deal.
The next 7 slides are a comparison of MiSeq to Ion Torrent:
Again I am not a bioinformatician so can’t realistically comment on the fairness of this comparison and others are getting the data for more impartial assessment.
The Ion data was all from the 314 chip which was specced at 10MB and the average run yield was 11-24MB from the threes tes that have generated data. So it looks like Ion is increasing the yield as expected. However it is very clear that the MiSeq has a huge advantage over the Ion platform with respect to yield as it gave 1.7Gb from this run. Quality on Ion was lower but without the stepped profile seen in MIseq and HiSeq, averaging out at Q31 vs Q19.
The comparison is an interesting one although it will probably be obsolete by the time I hit post due to the rapid developments from Ion. I did hear Broad have now obtained over 290Mb of data from a 316 chips so itt looks like their roadmap is on track.
It remains to be seen which platform is going to win this particular VHS vs Betamax battle (showing my age here). An unanswered question is also whether these platforms will ultimately replace systems like HiSeq, especially when whole genome sequencing can be purchased for $4000 with a 60 day turnaround. This could drop to $2500 next year if the 1Tb runs from Illumina work outside their development labs.
HiSeq costs $750,000 to buy including a cBot, MiSeq is $125,000. If yield is not your primary concern then MiSeq may well turn out to be the kind of instrument that finally democratises sequencing.
There has been a lot said about the recent sequencing of E coli from the recent outbreak in Germany. Over five isolates have been sequenced on almost every sequencing platform, HiSeq, 454, Ion and MiSeq. Interestingly I am not aware of a SOLiD or a Sanger genome. I’d recommend Genomewebs coverage as a good starter if you’re interested in finding out more.
Just this week Illumina made available a slide deck and data from their analysis of E coli K12MG1655 sequenced on HiSeq (PE100) and MiSeq (PE150).
The first 8 slides are the HiSeq MiSeq comparison:
Throughput seems to have gone up to 1.5Gb, which is a 50% increase over the initial specs so growth seems to be as fast on MiSeq as it has been on GA and HiSeq platofmrs. Albeit with just one data point so far. And there is still a,long way to go before it gets to 25Gb, see my first blog.
Libraries for the comparison were made using Tru Seq and not the Nextera kits from the recent Epicentre purchase which I was a little surprised about. Ot would have been great to see a multiplexed run on the two platforms for a TruSeq and Nextera comparison in the same data set.
Essentialy MiSeq outperforms HiSeq on quality a tiny bit. Other than that the datasets are pretty much the same n all respects. The HiSeq run has the characteristic intensity fluctuation at about 75bp where laser power is adjusted mid-run. Both runs have a stepped prfile in Men Qscore which I guess is a function of alignment getting better till about 20bp then declining with read quality. In this presentation Illumina do not show the Mean Qscore at 150bp for MiSeq.
Illumina sub samples the HiSeq run for a de novo assembly comparison and the result were strickingly similar in all respects other than MiSeq gave 11 where HiSeq gave 12 contigs. I am not an assembly wiz so can’t think why this would be the case nor whether it would matter a great deal.
The next 7 slides are a comparison of MiSeq to Ion Torrent:
Again I am not a bioinformatician so can’t realistically comment on the fairness of this comparison and others are getting the data for more impartial assessment.
The Ion data was all from the 314 chip which was specced at 10MB and the average run yield was 11-24MB from the threes tes that have generated data. So it looks like Ion is increasing the yield as expected. However it is very clear that the MiSeq has a huge advantage over the Ion platform with respect to yield as it gave 1.7Gb from this run. Quality on Ion was lower but without the stepped profile seen in MIseq and HiSeq, averaging out at Q31 vs Q19.
The comparison is an interesting one although it will probably be obsolete by the time I hit post due to the rapid developments from Ion. I did hear Broad have now obtained over 290Mb of data from a 316 chips so itt looks like their roadmap is on track.
It remains to be seen which platform is going to win this particular VHS vs Betamax battle (showing my age here). An unanswered question is also whether these platforms will ultimately replace systems like HiSeq, especially when whole genome sequencing can be purchased for $4000 with a 60 day turnaround. This could drop to $2500 next year if the 1Tb runs from Illumina work outside their development labs.
HiSeq costs $750,000 to buy including a cBot, MiSeq is $125,000. If yield is not your primary concern then MiSeq may well turn out to be the kind of instrument that finally democratises sequencing.
MiSeq vs HiSeq flowcell
So here it is, I was given one of these at AGBT and there is a picture in the MiSeq brochure. I thought I’d share an image with anyone wondering what they look like.
You can see it is very different from a HiSeq flowcell in that it is encased in a plastic housing. You can also see two inlet ports just above the ‘um’ in Illumina. These allow the much shorted and therefore faster fluidics to operate. The flowcell lane is bent back on itself, which is difficult to see in this picture.
I believe that only a portion of the MiSeq lane is imaged right now. But I am not exactly sure how much and this is key to working out how much data MiSeq might ultimately yield. A side-by-side comparison to a HiSeq flowcell shows that there is about 1/3rd the surface area of a HiSeq flowcell lane. Cluster density is being reported as the same on both platforms so if the clusters per mm2 is the same then a full MiSeq lane should generate about 1/3 the yield of a HiSeq lane.
However you could not access the increase in imaging area without spending more time on imaging. If Illumina and users are willing to increase the imaged area then yields will go up. MiSeq only images one surface right now, imaging both surfaces would generate a two fold increase but would double imaging time. If MiSeq is currently imaging one ‘surface’ from a possible two and one ‘tile’ from a possible three then it may be possible to increase out put by 6 fold. Of course I am not sure if this is possible and it relies on my assumptions about how MiSeq imaging works.
MiSeq is sold with very fast run times as a unique selling point and a single end 36bp run takes about four hours. If both surfaces can be imaged and three tiles rather than one are possible then the SE36 run time would go up to 6-8 hours but yield would jump from 0.3GB to 6Gb. For paired end 150bp runs this time would go from 1 to 2 days and yield would rocket from 1.5Gb to 9Gb. Run costs would not change.
I’d quite like my MiSeq to be shipped with a dial in the software that allows me to maximise data in the time I have available. If a run is going on overnight or the weekend for instance then why not let it run for longer and generate more data. This would be essentially for free.
More food for thought.
And ‘Yes’ that is James Watson’s signature on a HiSeq flowcell.
You can see it is very different from a HiSeq flowcell in that it is encased in a plastic housing. You can also see two inlet ports just above the ‘um’ in Illumina. These allow the much shorted and therefore faster fluidics to operate. The flowcell lane is bent back on itself, which is difficult to see in this picture.
I believe that only a portion of the MiSeq lane is imaged right now. But I am not exactly sure how much and this is key to working out how much data MiSeq might ultimately yield. A side-by-side comparison to a HiSeq flowcell shows that there is about 1/3rd the surface area of a HiSeq flowcell lane. Cluster density is being reported as the same on both platforms so if the clusters per mm2 is the same then a full MiSeq lane should generate about 1/3 the yield of a HiSeq lane.
However you could not access the increase in imaging area without spending more time on imaging. If Illumina and users are willing to increase the imaged area then yields will go up. MiSeq only images one surface right now, imaging both surfaces would generate a two fold increase but would double imaging time. If MiSeq is currently imaging one ‘surface’ from a possible two and one ‘tile’ from a possible three then it may be possible to increase out put by 6 fold. Of course I am not sure if this is possible and it relies on my assumptions about how MiSeq imaging works.
MiSeq is sold with very fast run times as a unique selling point and a single end 36bp run takes about four hours. If both surfaces can be imaged and three tiles rather than one are possible then the SE36 run time would go up to 6-8 hours but yield would jump from 0.3GB to 6Gb. For paired end 150bp runs this time would go from 1 to 2 days and yield would rocket from 1.5Gb to 9Gb. Run costs would not change.
I’d quite like my MiSeq to be shipped with a dial in the software that allows me to maximise data in the time I have available. If a run is going on overnight or the weekend for instance then why not let it run for longer and generate more data. This would be essentially for free.
More food for thought.
And ‘Yes’ that is James Watson’s signature on a HiSeq flowcell.
Monday, 20 June 2011
Why do the Chinese get such a good deal from Illumina?
Because they order 128 the day a new instrument is anounced and have deep pockets.
I have been following developments at BGI over the past three or so years and was as stunned as anyone else at their announcment of a 128 HiSeq 2000 order in January of last year. 128 instruments was a lot then and is still a lot today. Certainly the largest sequencing centre in the world and significanty more capacity than every country in the world except the USA and UK.
BGI has 137 HiSeq 2000s as well as 1x 454, 27x SOLiD and 1x Ion Torrent according to the google map of next gen sequencers. The US has 712, the UK 132 instruments each respectively.
Using the latest 600GB run chemistry they can put out 50Tb of data per week.
A recent Newsweek article profiles what is going on today over in Shenzhen. Note this BGI is nowhere near Beijing. It also specifies a price of just $500,000 for the HiSeq 2000. I thought $700,000 was nearer the mark so this represents about a 30% discount. Pretty good.
Now all anyone else need to do to realise a similar discount is spend $64M in a single purchase order. Reagents not included!
Roll on HiSeq version 2... ;-)
I have been following developments at BGI over the past three or so years and was as stunned as anyone else at their announcment of a 128 HiSeq 2000 order in January of last year. 128 instruments was a lot then and is still a lot today. Certainly the largest sequencing centre in the world and significanty more capacity than every country in the world except the USA and UK.
BGI has 137 HiSeq 2000s as well as 1x 454, 27x SOLiD and 1x Ion Torrent according to the google map of next gen sequencers. The US has 712, the UK 132 instruments each respectively.
Using the latest 600GB run chemistry they can put out 50Tb of data per week.
A recent Newsweek article profiles what is going on today over in Shenzhen. Note this BGI is nowhere near Beijing. It also specifies a price of just $500,000 for the HiSeq 2000. I thought $700,000 was nearer the mark so this represents about a 30% discount. Pretty good.
Now all anyone else need to do to realise a similar discount is spend $64M in a single purchase order. Reagents not included!
Roll on HiSeq version 2... ;-)
Subscribe to:
Posts (Atom)