HiSeq Low Read Count - Barcode in Read1

[tmm343]

Hello All,

I have a customer with their barcode at the very beginning of their read 1. I consistently am seeing a low number of raw reads as well as those PF. I am told it is a base diversity issue causing the HiSeq to not call all the clusters but I am not sold but am not certain how spot on this needs to be (Base diversity below). Any advice or insight would be greatly appreciated!

Thanks very much!

Cycle 1 2 3 4 5 6
A 25% 29% 38% 29% 29% 29%
T 42% 17% 29% 21% 21% 29%
C 13% 29% 17% 33% 17% 25%
G 21% 25% 17% 17% 33% 17%

[nucacidhunter]

Could you continue base composition up to cycle 12?

[tmm343]

Unfortunately I only have the first 6 bases as these are the barcode sequences I was provided with. The data has yet to be analyzed so I do not have the following base composition.

[nucacidhunter]

The low PF% could be due to low diversity in base composition following inline barcodes. Presence of restriction site or PCR primers after barcodes are two examples. RTA applies Chastity formula over the initial 25 bases. A cluster passes filter if 24 out of initial 25 cycles have a Chastity value >0.6. So, with low diversity chance of clusters not passing filter increases. Current work around is to spike-in 10% Phix and cluster lower than high diversity libraries. This will result in lower output but the quality of data for downstream analysis will improve significantly.

[SNPsaurus]

Has the HiSeq had its Control Software updated to HCS v2.2.38? That improves low diversity sequencing significantly.

[tmm343]

nucacidhunter,
The samples are RNA-seq libraries so I assume after this initial 6bp barcode the base composition should be pretty diverse. My overal raw reads was extremely low as well even while I loaded at my usual concentration.

SNPsaurus,
Yes this is on the new update HCS software. Also I have been seeing worse PF across the board for low and high base diverse libraries since I've upgraded the software.

[GenoMax]

Someone else had reported a problem recently with HCS 2.2.38: http://seqanswers.com/forums/showthread.php?t=48194

It would not be the first time a company has released "upgraded" software that takes things in the wrong direction. Make sure you report this to Illumina tech support. If this is a real problem then they are likely to do something when several people report it as an issue.

[nucacidhunter]

nucacidhunter,
The samples are RNA-seq libraries so I assume after this initial 6bp barcode the base composition should be pretty diverse. My overal raw reads was extremely low as well even while I loaded at my usual concentration.

I would not rule out issues with software or instrument, although we have not had any issues with it. Other possibilities to explore:

1) Cluster density and if they are within range for the SBS chemistry and machine.

2) If they are within range or lower, check thumb nails for potential over-clustering that has not been reported by RTA. Also check sum of top and bottom surface first base report. If it is significantly higher than reported cluster density, would indicate unreported ove-rclustering.

3) Other signs of over-clustering include higher density in upper tiles than lower ones or variable cluster density throughout the tiles that can be checked on SAV.

If over-clustering ruled out, then issue could be chemistry and library prep. Using inline barcode for RNAseq is unusual, so I would suspect that they are custom designed. Potential issues with this approach are design fault and low grade synthesis of adapter oligos which could give rise to incorrect bases thus affecting sequencing primer hybridisation and phasing issues. Phasing issues also can occur with using low grade custom primers. These issues can be checked by comparison of phasing/prephasing with successful runs.

[tmm343]

1) Cluster density and if they are within range for the SBS chemistry and machine.
The cluster density looks low as reported by SAV. 400-600 range.

2) If they are within range or lower, check thumb nails for potential over-clustering that has not been reported by RTA. Also check sum of top and bottom surface first base report. If it is significantly higher than reported cluster density, would indicate unreported overclustering.
The image files were checked and they do not seem to be under or over clustered. This is why there was the thought that the new software was under-estimating the clusters.

3) Other signs of over-clustering include higher density in upper tiles than lower ones or variable cluster density throughout the tiles that can be checked on SAV.
There is variable cluster density throughout the flowcell. The back region is reporting lower cluster density then the front region of the flowcell. I would think this was a fluidics problem but we have not seen an issue when we did our checks.

Thanks everyone for the great feedback and advice! I really appreciate it.

[HeinKey]

We have been running low diversity libraries from the early GA times on. We used a dedicated lane with Phi-X to calculate the metrix values. This is no longer necessary with the newest RTA versions anymore. These versions can handle low diversity libraries very well. And that's also our experience!

The percentage numbers you present should not be a problem at all for the RTA. Not even for the old RTA versions. These percentages do not cause the low number of reported cluster densities.