Can we stop the run and re-generated the cluster on flow cell on MiSeq?

[runsheng]

We are using the MiSeq machine (2*250, V2 kit) for a Truseq library sequencing. As we find the cluster density is low (only 239k) on the cycle 3, can we just stop the machine now and add additional libraries and re-run the protocol?

Because the MiSeq machine used to report an error just after the cluster generation step. We washed and restarted the machine, and all process worked fine. I just wondering if I can do that again on cycle 3.

add:
The run continue and yield 2.7G result at last. The normal run with density 800K should yield 7.5G data.

add:
We quantified the libraries with real-time PCR using KAPA kit.

[microgirl123]

As far as I know, you cannot stop and restart the MiSeq. You should try to figure out why your cluster density is so low. How did you quantify your libraries before loading them on the MiSeq?

[runsheng]

As far as I know, you cannot stop and restart the MiSeq. You should try to figure out why your cluster density is so low. How did you quantify your libraries before loading them on the MiSeq?

We quantified the libraries with real-time PCR using KAPA kit. It works well for the RNA-seq libraries with insertion size ~500bp. As for the DNA library (insertion size ~800), the concentration should be lower than the calculated one, adjusted as 5/8.

[microgirl123]

Interesting. Have you contacted Illumina tech support? The last time I saw such low cluster densities on a properly-quantified run, there was a problem with the optics.

[Jessica_L]

microgirl is right-- you can't just switch the instrument off and on and re-cluster a flow cell.

The end of the cluster gen process includes a 3' blocking step that prevents extension of DNA template and flow cell oligos (which would interfere with bridge amplifying any new libraries you might add in an effort to boost cluster counts). The only work around I can think of would be to run a deblock step similar to what happens during the PE turnaround but I don't know how you would do that manually. You would still have to worry about having enough reagents to repeat clustering from the same reagent cartridge, though.

[runsheng]

Interesting. Have you contacted Illumina tech support? The last time I saw such low cluster densities on a properly-quantified run, there was a problem with the optics.

I guess the machine should be all right cause we just got a normal run for RNAseq one week ago.

We have analysed the data generated from this run. Though with a low density and yield, the read seems to be fine and even get a little bit higher Q30 percentage than our former runs (with >800 cluster density). The quality, read length, read yield for each index and read mappbility all seem to be OK.

The only flaw is the read coverage, we expected a 8X coverage but now we only get 3X.
And that's why I asked if I can re-do the cluster generation process.

[runsheng]

microgirl is right-- you can't just switch the instrument off and on and re-cluster a flow cell.

The end of the cluster gen process includes a 3' blocking step that prevents extension of DNA template and flow cell oligos (which would interfere with bridge amplifying any new libraries you might add in an effort to boost cluster counts). The only work around I can think of would be to run a deblock step similar to what happens during the PE turnaround but I don't know how you would do that manually. You would still have to worry about having enough reagents to repeat clustering from the same reagent cartridge, though.

Thank you for reply!
Indeed we have re-generated the cluster once. At that time, we encountered an error after the cluster generation step and the machine was halted on cycle 1. After wash and restart, the run completed normally and yielded full data.

The 3' blocking is still a ddNTP blocking for MiSeq?

[HeinKey]

hi Runsheng,
I understood you compared an 800 nt library qPCR result with a 500 nt library, and corrected loading with 5/8.
This seems logical given both libraries cluster equally efficient.
This is not the case. Shorter fragments cluster far more efficient.
That is probably why you got a lower cluster density than expected.