Hiseq max cluster density?

[fffhiseq]

Hey, any one came across the upper boundary of desired cluster density on Hiseq2000. Above what level of clusters there will not be any intensity detection?

[csquared]

A bit over 1M cluster/mm2

[RPiddock]

I would agree with that, above that and the passing filter bombs in the majority of cases.

[vtosha]

We got on GAIIx 1M/mm2, after filtration 600 K. Intensity was detected. Techsupport said about lane overload, but we got good results when assembly have done.

[TonyBrooks]

You seriously have to overload to get no data at all.
What happens as you increase concentration is that more and more reads (as a percentage of raw reads) fail the filters and you also start to get quality problems. The Q-score is based a number of statistics, some of which depend on being able to distinguish clusters from each other (which obviously is more difficult the more clusters there are).
Optimum cluster density is around 800-850k/mm^2 according to Illumina, but we've had over 1M/mm^2 and still got data loads of data out at the end with acceptable Q-scores. I guess some of that also depends on the nature of the library - a more biased or lower diversity library may cause problems at high density.
Routinely, I'd aim for 800k/mm^2 as you should get decent data regardless of the library.

[fffhiseq]

Thanks to all for the comments. basically we got cluster density in the range of 1100k+/-50/mm-2 on hiseq2000 with flw cell v3 and got 0% pass filter for all the sample except one with32% PF and PF reads 102M. samples dilution of10pM was used and Phix 8pM. Phix gave cluster density of 350k/mm2. it must be overloading but all Qc were performed on Bioanalyzer DNA1000 and qubit. it seems that it is important to run a titration flow cell before running the experiment.

[vtosha]

Yes, it is a problem with defining of concentration. I used 16 pM (Qubit) on all lanes and some lanes gave a 1M, phiX gave a 350k, and library on self-made adapters gave 400 K.
Real-time gave a some-fold concentration higher than Qubit. And we observe a different concentration of phiX libraries from some deliveries (eight-fold difference on Qubit and real-time).
TruSeq Sample Prep kits give very high cluster density from libraries, so be care of high concentration of libraries.

[fffhiseq]

@vtosha
yeah our qPCR showed four fold difference as compared to the qubit concentration. tech support shud redefine the parameters for the loading. else for first timers it is difficult without loading a titration flow cell.

[vtosha]

Our training teacher insisted on that Qubit data more valid.

[fffhiseq]

In our experiment we followed qubit readings but in real it underestimated or illumina recommendation is too large to be load on the flow cell. we too were told the same thing to follow fluoroscent based DNA quanti estimation.

[GW_OK]

You also can't really trust cluster scores that are over 1 million. The last time I overloaded a lane (after trusting the Qubit and not qPCR) I had clusters of ~1.2 million but ~60% passing filter. In talking with someone at illumina apparently the cluster finding algorithm starts not working properly at densities over ~ 1 million, and you may actually have a significantly higher cluster density that what it reports, it just can't handle it all.

[LaoR]

I remember Illumina mentioning in one of their talks that qPCR is the "gold" standard in terms of quantifying.

For the HiSeq 2000 that we are using, having a 2nM (from qPCR) and loading with 12pM on the cBot usually hits the 1 mil mark. It's risky hitting near max thought; you can get more data from higher cluster densities or nothing at all if you over cluster.

[HESmith]

You should be aware that high cluster densities (900-1000K) have a more deleterious effect on index reads than inserts. We've had several flow cells with good cluster calling (80-90% PF) and high quality scores (mean ~38), yet fewer than 50% of the indices were called accurately. In some cases, pseudotiles at the inflow side (which contain higher cluster densities) have completely dropped out (i.e., no basecalling) during the index read after producing high-quality insert reads. The problem can be mitigated by balancing the ratio of index bases at each position. It is not solved merely by having different bases at each position if those bases are excited by the same laser (A/C or G/T).

[huguesparri]

Same as HESmith here.
If you have multiplexed samples, you should not go higher than 800-850 k/mm² or the machine will have trouble reading the index and you'll loose information.

[pmiguel]

You should be aware that high cluster densities (900-1000K) have a more deleterious effect on index reads than inserts. We've had several flow cells with good cluster calling (80-90% PF) and high quality scores (mean ~38), yet fewer than 50% of the indices were called accurately. In some cases, pseudotiles at the inflow side (which contain higher cluster densities) have completely dropped out (i.e., no basecalling) during the index read after producing high-quality insert reads. The problem can be mitigated by balancing the ratio of index bases at each position. It is not solved merely by having different bases at each position if those bases are excited by the same laser (A/C or G/T).

I have some hope that HCS 1.5.0 has improved index calling rates. (On the down side we were shut down for 3 weeks after installing 1.5.0. The upgrade failed to update a critical line in a config file. The result of this was that flow cells frequently, but not always, failed to find the edge of lane 8 and refused to start cycle 1 scanning.)

We always try to "MK balance" (M=A,C ; K=G,T) our indexes in a lane. By which I mean (as you imply above) you want a good number of clusters in the A or C channel AND plenty in the G or T channels as well. But a response to my post about this made me think this was not really an issue for the HiSeq, only for HiScanSQs.

Anyway, we have a lane with a mean cluster density of 950 K/mm2. 94% of the PF reads demultiplexed. (3 indexes.) That does seem better than what we were getting with previous versions of HCS.

--
Phillip