Reduced Representation Bisulfite Sequencing for Methylation Analysis

[audioPL]

Dear All,

I am thinking about the Reduced Representation Bisulfite Sequencing method (RRBS) for Methylation Analysis. I found on the Illumina web site the RRBS Analysis Guide (https://icom.illumina.com/download/s...z0ae9IHZZoA8dg). Everything looks good except the Methylation Adapter Oligo Kit catalog # ME‐100‐0010. This kit seems to be unavailable! So, I guess Illumina recommends the method that is out-of-date, at least in some part.

I would like to ask you which method you could recommend for the RRBS? Let’s assume that I have ds-metDNA fragments (150-300bp) and I want to ligate methylated adapters, then BS conversion, preamp in PCR and PE-seq (most preferably 2x150 on MiSeq but if MiSeq is incompatible with the kits, other systems can be used). Does Illumina offer methylated adapters and compatible primers that I could use? I will be grateful for your help.

Bests,
audio

[genbio64]

Dear Audio,
No Illumiuna does not offer methylated adapters to my knowledge as we have to custom order them.

[audioPL]

Dear genbio64,

Thank you for your reply. Can anyone else confirm this unfortunate info, please?

If so, could you please recommend a good, recent publication where the methylated adapters and primers are described? Moreover, the adapters should be compatible with the 2x150PE non-directional sequencing method. I will be grateful for your suggestions.

Bests,
audio

[cnicolet]

The adapters in Illumina DNA sample prep kits are methylated, so can be used for bar-coded bisulfite libes. We have made many of these. The only downside is the oligos are expensive since we basically don't use the rest of the kit!
I had my own RRBS question, are people having difficulties getting good %PF on the Hi-Seq since the first 2-4 bases are the same in these libes?

[simonandrews]

We've spent a lot of time working out how to deal with biased libraries such as those you get from RRBS experiments, and whilst we had a really efficient way to work with these on the GAs we've hit a whole new batch of problems on the HiSeq.

The original problems were summarised (with a work round) in this paper. On the HiSeq there seem to be a couple of additional problems though:

On the HiSeq the RTA software has changed how it does cluster detection. On the GA and in OLB the cluster detection used to be carried out over the first 4 (or in later relases 5) bases and any difference in any of these bases was enough to detect a difference. In the new RTA it apparently only looks at the first 4 bases, and then it selects the 'best' 2 of these to use for analysis. Unfortunately the illumina person we spoke to couldn't tell us on what basis the 'best' bases were chosen but from a practical point of view selecting the wrong base can be very bad for your data.

If there are very biased bases within these first 4 bases then two bad things can happen.

Firstly if you don't have any signal in the two 'colour' bases (I forget which these are, it's T and something else I think) then the focusing can get messed up. Since the HiSeq only does a full focus in the first few cycles and then does minor adjustments then if this gross focus gets messed up initially then it may be rubbish through the whole run.

Secondly, if either of the two cycles picked for cluster detection turns out to not be diverse then the cluster separation will be very poor, and lots of clusters will end up with mixed signals in later cycles and be kicked out by the purity filter.

What this means in practice is that you can't have completely biased bases in the first 4 bases of any library. If you have a library like this you can run some 'dark' cycles initially to skip over the biased bases before starting the imaging part of the run (illumina can supply a custom recipe to do this), but you'll also lose the sequence from those cycles.

If you use custom adapters with 5' barcodes on them then these will work efficiently only as long as the barcode is at least 4bp in length. Any less than this and you risk picking the 'T' cycle (from the overhang) as one of the two key cycles at which point you get losses of around 50% (from our experience).

[cnicolet]

Thanks for the info, your experiece mirrors ours. I was hoping someone had good tricks to fool the computer/software. We have done these runs on the GA using the prescribed settings and it worked great. There's a lot I miss about the GA! Illumina's main suggestion is to add phix to about 30%, according to tech support that gives enough color balance to define all the clusters.

[simonandrews]

Even 30% phix won't give enough diversity to solve the problem of touching clusters not being separated since there's still a 70% chance that two touching clusters will be biased sequence.

On our site we've actually moved to doing whole genome bisulphite sequencing rather than RRBS now, but if you still need to do RRBS I'd be tempted to either put a random adapter on the front of the sequences, or to dark cycle the biased bases. You'd need to work out the numbers but I suspect either of these might give you a higher overall yield than adding PhiX.

We've also been tempted to try saving all of the image data from a Hi-Seq run. We have enough temporary storage to do this but haven't actually risked it yet. As long as the network connection can transfer the data fast enough I can't see why that wouldn't work and you could use the same work-rounds as for the GA.

[cnicolet]

Thanks for the info! We primarily do WGBS but had a customer with RRBS (love acronyms). We have had other tech issues with WGBS though and I would be grateful if we could initiate a dialog and compare protocols. My email is [email protected], if you're willing. Thanks!

[ofedrigo]

Sorry, it may be a naive question. How do you implement "dark cycles" on your miseq or hiseq?

[simonandrews]

Sorry, it may be a naive question. How do you implement "dark cycles" on your miseq or hiseq?

You need a custom recipe which has all of the chemistry components but excludes the imaging steps. In our case our Illumina rep provided this for us so if you ask yours they should be able to give you something suitable for your libraries.

[MarcoT]

If you use custom adapters with 5' barcodes on them then these will work efficiently only as long as the barcode is at least 4bp in length. Any less than this and you risk picking the 'T' cycle (from the overhang) as one of the two key cycles at which point you get losses of around 50% (from our experience).

I was actually wondering how much of a problem is the "T cycle". I am planning to use adapters with a 4bp in-line barcode. In your experience would it be best to have all adapters of the same length (therefore the 5th base will be a T in all reads) or to design staggered 3bp and 4bp adapters, to spread the overhang problem between the 4th and 5th base? I wouldn't want to use longer barcodes if it is not necessary. I am hoping to use different 4bp barcodes on each side of the insert to minimize the number of adapters, and using longer adapters would means sacrificing more actual sequences.

Thanks!