Poly-G Failed Runs on NextSeq

[djs150]

Approximately a month ago, our lab performed an RNASeq using a TruSeq Stranded mRNA library prep and a v2 75cyc High Output flowcell. The data that came back was almost entirely G's and was severely underclustered. When we went to re-run the same library, the machine died and would soon thereafter require all of the boards to be replaced.

We assumed that the poly-G run was an early symptom of the board failure, until we tried to run a genomic library prepared with Nextera DNA reagents on v2 300cyc High Output flowcell and again got nearly all G's (also very underclustered). There were no shared reagents between the two library preps and our lab has performed many of each type of prep without failure.

Thinking that it was a hardware issues still, we did a phiX run on a 300cyc Mid Output flowcell... which of course came out perfect. Illumina is of the opinion that it is a transient issue and that we should just continue trying, but there's got to be more to it than that. Have any of you run into this problem before or have thoughts on what may be going on?

[GenoMax]

Have you tried to sequence the libraries on a different sequencer?

[djs150]

We have not tried them on a different machine yet. Illumina was first insistent that it was a library prep issue, so at the time it seemed wasteful to run on a separate machine.

[GenoMax]

You may want to spike one of the libraries with someone else (as long as the tags allow) who may be running on a MiSeq/HiSeq. That would confirm that quality of your libraries before you try a re-run on NextSeq.

[wdecoster]

Given that NextSeq uses two color chemistry, poly G essentially means an absence of signal...

[Tim NGS]

Make sure no custom primers were selected during the run setup. Information can be found at bottom of the "runparameters.xml"-file. Just look for "<UsesCustomReadOnePrimer>true"

Sounds stupid, but we also had it once when the custom primer button was pressed accidentally when initiating an experiment. The system will use the wrong primer for first read sequencing, so no signal is generated and thus no clusters will be detected. Due to the chemistry, there is no signal from G-bases. Run will look severely underclustered and possibly only G's will be called.

[djs150]

At this point, I welcome things that sound stupid if it means we can get this wrapped up. Unfortunately the run parameters show false for the custom primers and everything else in there looks as expected.

[GenoMax]

Only options I see is to cross your fingers and try a re-run with NextSeq or check the libraries on a MiSeq/HiSeq to confirm that they are sequenceable before coming back to NextSeq.

[djs150]

As an update, we've now run the same library on a different NextSeq and obtained the same results. The library was run with a 1% PhiX control, which sequenced perfectly.

We thought that, due to the high GC nature of the libraries, the strands weren't denaturing. The NaOH stock used was over pH 13 and a Qubit before and after denaturing showed that they are certainly single stranded when they are being loaded.

So the problem is in the library prep, somewhere. The only common reagent is the Omega Bio-tek beads from the PCR clean up. Is there any rationale that the beads could be causing this problem somehow?

[GenoMax]

This is likely an indication of a bad library prep and you may be better off starting over.

As a last try do a MiSeq run, if you can. MiSeq is a resilient sequencer and may be able to sequence this sample. Having 4 color chemistry helps as well. If the library has low nucleotide diversity then increase the phiX concentration.

[Brian Bushnell]

I think if the same library failed with the same error mode on a different machine, it would be a waste of resources to run it again. Considering the PhiX reads sequenced perfectly, I cannot imagine that a different platform would give different results. It sounds like you just don't have any sequence (since as wdecoster noted, 'G' means no signal). But to clarify, are the sequences 100% G, or are they ~60bp of adapter and then poly-G?

[GenoMax]

I think two separate libraries were originally tried but at least one of the libraries was run again and failed.

If this is an irreplaceable sample then try the last ditch effort I mentioned above otherwise I agree that it would be best to start over and make new libs.

[Brian Bushnell]

If this is an irreplaceable sample then try the last ditch effort I mentioned above

Good point, I did not consider that aspect. If that's the situation I concur with Genomax.

[djs150]

They are 100% G, adapter and all. And yes, there were originally two unrelated libraries that failed and the second was re-run on a different machine.

The samples are by no means irreplaceable as we have the original DNA to remake the libraries. However, if I'm missing something obvious that is going to lead to another failed run (i.e. bad reagent), then remaking the libraries isn't going to help.

I'm simply at a loss to explain why Qubit and Tapestation indicate there is tons of DNA there and yet I can't seem to get a viable read on in it.

[Brian Bushnell]

I wonder if...

A) The adapters never attached to the reads
or
B) The reads were to long to bridge-amplify (in which case a different platform might make a difference)

I don't know how to diagnose those issues, but they seem like the most likely culprits to me.