[pmiguel]

Great!
Hmm. Looks like some lanes fared better than others at higher densities. Could you share which indexes were in each lane?

--
Phillip

[westerman]

I doubt that someone with 1200+ posts on this forum would be in the "desperado" category

You obviously haven't seen a picture of Phillip. His dark long hair and long beard plus steely gaze is enough to make the most stalwart biologist tremble at the thought of putting their precious samples into his hands. A hundred years ago he would have been known as the 'Sequencing Kid' ready to take on all comers.

We will get the indexes early next week. I have my fingers crossed hoping that they look good despite the high cluster densities.

[pmiguel]

Indexes and density.

At the densities we see, there seemed to be no density-dependent impact on index demultiplexing (I have restricted these to the indexed lanes, 2-7 and the index cycles, 102-108):



Well, okay that just shows quality. But from the "Indexing" tab of SAV, all lanes with indexes (2-7) demultiplexed >98% of the PF clusters.



Here are all the cycles thus far.
The low quality cycle-tiles derive either from "Bottom Middle Swath" events or index cycles from non-index (v3) phiX lanes (1,8).

Could be the result of:
(1) Density not all that high? But some tiles were above 1100 K clusters/mm^2.
(2) Newest HCS/RTA version less sensitive to density.
(3) New instrument laser gives higher signal, thus higher signal/noise

Anyway, the HiSeq does not appear to have the requirement that each cycle have AC/GT channels populated with clusters to prevent mis-focusing. Lane 7 above has a single index in it. Nevertheless it "demultiplexes" fine. Actually since all 4 channels are being scanned with different lasers (if I understand correctly.) This is not surprising.

--
Phillip

[MLog]

Anyway, the HiSeq does not appear to have the requirement that each cycle have AC/GT channels populated with clusters to prevent mis-focusing. Lane 7 above has a single index in it. Nevertheless it "demultiplexes" fine. Actually since all 4 channels are being scanned with different lasers (if I understand correctly.) This is not surprising.

--
Phillip

Doesn't this mean that any combinations of indices should work equally well?
If so, my impression is exactly the opposite - when we ran two samples with barcodes 12 and 7, we failed to demultiplex about 30% of reads. The explanation that Illumina support gave us "the problem is with the choice of barcodes. To ensure indexed reads perform optimally try to ensure you have one base from the green channel (G or T) and one from the red channel (A or C) at every cycle."

[pmiguel]

Doesn't this mean that any combinations of indices should work equally well?
If so, my impression is exactly the opposite - when we ran two samples with barcodes 12 and 7, we failed to demultiplex about 30% of reads. The explanation that Illumina support gave us "the problem is with the choice of barcodes. To ensure indexed reads perform optimally try to ensure you have one base from the green channel (G or T) and one from the red channel (A or C) at every cycle."

On a HiSeq? What you describe is exactly correct for a HiScanSQ. But with a HiScanSQ a single bar code will rarely "demultiplex" at rates above 50%. Whereas our HiSeq (first run) has no difficulty "demultiplexing" the single index.

We are used to "balancing" our indexes for the HiScanSQ, so we will probably continue to do so.

--
Phillip