Monday, 29 September 2014

A cheat's guide to histone modifications

I was recently having lunch with Sandro, a charming Neapolitan computer science graduate doing a postdoc in my research group, who has a passion for great food and clean C code. We were discussing some recent aggregation results of histone modifications, and Sandro was bemoaning (verbally and non-verbally) the fact that all the histone modifications sounded "just the same". I could relate to the sentiment, recalling my own journey into this world some seven years ago during the start of the ENCODE project when I first faced this bamboozling list of modifications.

Here's my take of histone modifications. It's probably a reasonably accurate snapshot of what we knew by the end of 2013. (There is a lot more to cover, and this view will surely go out of date fairly quickly. If you are reading this post in 2016, you might want to look for your cheat sheet somewhere else!)

So - this summary is mainly for Sandro, but I am pretty sure there are others who might like to use it.

Preliminaries

Histones are proteins that package up DNA. The combination of histones and DNA is called "chromatin", and this is the natural way one finds DNA in eukaryotic cells. Histones come as two groups of four proteins in a unit, called a nucleosome.

There are different types of histone protein. And just to be extra confusing, the same type of histone protein is sometimes made by more than one gene. (A lot of histone protein needs to be made during each cell cycle.)

Histone proteins are mainly compact, globular structures, but each one has a floppy peptide region at the start of the protein, which is described as the histone "tail" (somewhat confusingly in my view, as it's at the start of the protein! Isn't it more like a "trunk"?). These histone tails have many lysines (single amino acid code, K) which can often be modified chemically with the addition of a methyl group (CH3) or an acetyl group (CH3CO; alcohol, basically).

Modification themes


There are some strong themes that emerge in the sets of modifications, and the most important rule for recognising them is that a particular lysine can have either 1, 2 or 3 methyl groups, or one acetyl group. There are other combinations and modifications, but this rule (lysine in one of four states) is the main one.

There are many different histone proteins, and each protein has many different lysines. Because the histone modifications were first described biochemically, they had a standard naming scheme, for instance H3K4me3, or H3K27ac. The naming  scheme is:
  1. H is for histone (H3K4me3)
  2. The next number is the type of histone protein. Much of the action happens on histone 3 (H3K4me3)
  3. The next letter is amino acid that is modified. It is very often lysine: K (H3K4me3)
  4. The next number is the residue of that amino acid. Remember, the histone tail is at the N-terminus, so it is often a small number (H3K4me3)
  5. The next group is the modification. It might be me1 (mono-methylation), me2 (di-methylation), me3 (tri-methylation, as in the example) or ac (acetylation). (N.B. 'me' by itself is ambiguous, but 'ac' by itself is not.)
This is great if you are interested in the precise chemical makeup of the modifications. However, most people are interested in the implications for the cell. To be honest, I think we would be better off giving each one of these modifications a distinctive name, as they do in Drosophila gene naming schemes, but... this is what we've got. 

Histone modifications and chromatin behaviour

Histone modifications are observed across the genome, but are very different in different parts of the genome and in different cell types. There is a raging debate about whether histone modifications can be considered to drive chromatin behaviour, or whether chromatin behaviour is simply a consequence of things which are  happening nearby on the chromatin (in particular, transcription factor binding) (I am mainly a "consequence" person here). Either way, these modifications are extremely informative about what is going on in any given cell type. 

Another thing to keep in mind is that "pairs" of histone modifications can be found on the same residue. Very often, one of the pair is more about activation and the other about repression, or put another way, one features promoters and the other enhancers. Having a pair forces a sort of duality in which any particular histone has to be in one state or the other.

Well-known modifications: some notes

The H3K4me3 vs H3K4me1 pair: promoters vs intergenic

H3K4me3 is the classic histone modification, and an active mark. It was discovered early on, and is usually present on active promoters in a tight, localised area (and elsewhere, though perhaps these are mainly unannotated promoters?). H3K4me3 is your go-to histone modification to help define a promoter. 

H3K4me1 is kind of its opposite, as it is present far more in intergenic regions, including many "enhancers", through both active and inactive enhancers. H3K4me1 is more enigmatic than H3K4me3, and is a slightly less localised mark. 

H3K4me2 is (normally) tightly correlated with H3K4me3, and I think of it as really on its way of getting its third methylation to become H3K4me3.

Although H3K4me3 is activating, just to make life confusing, the other me3 modifications are, for the most part, repressive. (Biology is shameless about lack of consistency sometimes!)

The H3K27me3 vs H3K27ac pair: repressed vs active

H3K27me3 is the classic repressive histone modification. You find it in regions of the genome that are deliberately switched off. One of its most famous associations is with the polycomb complex, which is a chromatin-organising system that provides cellular memory, particularly during development.

H3K27me3 is also present on the inactive X chromosome. In common with most other repressive marks, H3K27me3 is far more diffuse, and there are mechanisms that take an initial H3K37me3 region and expand it "automatically"

In contrast, H3K27ac is a strong, "active" mark, and shows activity over both active promoters and active enhancers. As this is happening in the same residue, you can see that this system is being set up nicely to be either active or repressed. 

The H3K36me3 and H3K79me2 pair: transcriptional repression

These two marks are not opposing pairs (notice they are not on the same residue), but they do similar jobs: they essentially provide extra repression of transcription initiation in gene bodies. 

When a gene is transcribed, there is this huge, hulking protein complex (RNA polymerase) that is marching through the chromatin, making it far easier for cryptic promoters in the DNA sequence to be activated. This would lead to a mess (in particular if they were going anti-sense), except that the RNA polymerase deliberately comes to the rescue with a histone modification scheme that puts down a "don't start transcription here, because I am transcribing through this region" message: H3K36me3. This means this mark is indicative of polymerase activity, and in theory should be relatively flat across a gene body. 

H3K79me2 is the same thing, but only at the start of the gene, whereas H3K36me3 picks up after the first bit.

The H3K9me3 vs H3K9ac pair: repeat repression vs active

The H3K9me3 vs H3K9ac pairing is another repressed vs active pair, though you mostly hear about the repressive form because it is very often used on repeats. Repeats in the genome are genomic parasites which, when active, are happily copying themselves around the genome. The host genomes have some pretty ingenious ways to detect and repress these repeats. The final "effector" of repression is very often H3K9me3 deposition. 

There is also something weird going on with H3K9me3 and zinc finger genes. 

... and many more

There are many other modifications, many of which people don't actually know much about - for example the common but mysterious H4K20me1. But I'll keep this post to the classics - you can delve in to the 10s - 100s or so mysterious ones through many papers. 

Sandro - I hope this was useful :)

Tuesday, 26 August 2014

CRAM goes mainline


Two weeks ago there was the announcement from John Marshall from Sanger for SAMtools 1.0 - one of the two most widely used Next Generation Sequencing (NGS) variant-calling tools embedded in hundreds if not thousands of bioinformatics pipelines worldwide. (The majority of germline variant calling happens either through SAMtools or the Broad's GATK toolkit.) SAMtools was started at the Sanger Institute by Li Heng when he was in Richard Durbin's group, and stayed at Sanger now under the watchful eye of Thomas Keene.  

The 1.0 release of SAMtools has all sorts of good features, including more robust variant calling. But a real delight for me is the inclusion of CRAM read/write, which is a first-class format similar to SAM or BAM. SAM started this all off (hence the name samtools), and BAM was a binary and "standard" compressed form of SAM. CRAM was written to be compatible with the data model from SAM/BAM, and its main purpose is to leverage data-specific compression routines. These include reference-based compression of base sequences, based on work done by Markus Hsi-Yang Fritz and myself (blogged here, 3 years ago).

CRAM also brings in a whole set of compression tricks from James Bonfield (Sanger) and Vadim Zalunin (EMBL-EBI) that go beyond reference-based compression. James was the winner of the Pistoia Alliance's "Sequence Squeeze" competition, but sensibly said that his techniques would be best used as part of CRAM. James was instrumental in splitting out his C code into a reusable library (htslib), which is part of what SAMtools is built on. There is a whole mini-ecosystem of tools and hooks that enable reference-based compression to work, including a lightweight reference sequence server developed by Rasko Lenionen at EMBL-EBI. 


Elegant engineering


SAMtools is basically about a series of good engineers (John, James, Vadim and others) each working on different components for NGS processing, under the bonnet - with the Sanger and EMBL-EBI investing considerable effort into making the machinery come together. Just as an internal combustion engine requires more complex engineering than mixing fuel, igniting it and making a car go, good engineering takes more than a proof of principle. Really elegant engineering is invisible, and that is what SAMtools offers: it just works. It has been great to see John and James work CRAM into this indispensable piece of software, and for Sanger coordinate the project so well.

Space saving and flexibility

With this release CRAM becomes part of the natural SAMtools upgrade cycle, so when people upgrade their installation they will immediately see at least a 10% saving on disk space - if not better. If they allow the new Illumina machines to output the lower entropy quality values (this is the default), the savings will be more like 30-40%.

Another practical benefit of CRAM is its future proofing: CRAM comes "out of the box" with a variety of lossy compression techniques, and the format is quite flexible about potential new compression routines. We've seen that the main source of entropy is not the bases themselves, rather quality values on DNA sequence bases. CRAM provides options for controlled loss of precision on these qualities (something Markus and I explored in the original 2011 paper). It's important to stress that the right decision for the right level of lossy compression is best done by the scientist using and submitting the data. It might be that community standards grow up about lossy compression levels - its important to realise that in effect Illumina is already make a huge host of appropriate "data loss" decisions in their processing pipeline, most recently the shift to a reduced entropy quality score scheme. The first upgrade cycle will allow groups to mainline this and give them the option to explore appropriate levels of compression.

The Sanger Institute has been submitting CRAM since February 2014. And in preparation for the widespread use of CRAM - with the option of lossy compression - the European Nucleotide Archive has already announced that submitters can choose the level of compression and the service will archive data accordingly. Guy Cochrane, Chuck Cook and I also explored the potential community usage of compression for DNA sequencing in this paperSo we have solid engineering, a flexible technical ecosystem and have prepared for the social systems in which it will all work.


R&D ...&D ...&D

When the first CRAM submission from Sanger to EBI happened about a year ago, I blogged about how well this illustrates the difference between research and development. Our research an proof of principle implementation on data-specific compression of DNA took perhaps 1.5 FTE years of work, but to get from there to the release of SAMtools 1.0 has taken at least 8 FTE years of development. In modern biology, I think we still underestimate the amount of effort needed for effective development of a research idea for infrastructure deployment, but I sincerely hope this is changing - this wont be the last time we will need to roll in a more complex piece of engineering.

SAM, CRAM and the Global Alliance for Genomics and Health

CRAM development has come under the Global Alliance for Genomics and Health (GA4GH), a world-wide consortium of 200 organisations (including Sanger and the EBI) that aims to develop technologies for the secure sharing of genomic data. CRAM is part of the rather antiquated world in which specific file formats are needed for everything (all the cool kids focus on APIs these days). But also represents an efficient storage scheme for the more modern API vision of GA4GH. APIs need to have implementations, and the large scale "CRAM store" at the EBI provides one of the largest single instances of DNA sequence worldwide. Interestingly the container based format of CRAM has strong similarities with row-grouped, column orientated data store implementations, common in a variety of modern web technology. We will be exploring this more in the coming months.


Upgrade now, please.

The main thing for the genomics community is to now upgrade to SAMtools 1.0. This will give you many benefits in the whole short read calling and management, and one of those will be being able to read/write CRAM directly. If you do this it will have a considerable saving in disk for your institute and for us at the EBI. It will also help ensure we're all prepared for whatever volume of data you might be producing in the future.