Why illumina index is read separately?

[sharpo]

Hi.

illumina has total 3 reads (see attached image):
1. Read1 > followed by removal/wash-off of Read1 product
2. Index read (read separately after binding of Index Primer downstream)
3. Read2

Any idea why Index can't be read continuously down as part of Read1? Has this something to do with the sequencing length limit of Read1 or some other technical constraint?

Thank you!

[GenoMax]

In theory when the insert is shorter than the read length you do read into the adapter at other end and then will sequence the index. Problem is not all inserts in your library are the same length and may not even be shorter than read length. So you would not be guaranteed to reach and read the index each time. One would want the indexes to be read consistently so a separate primer is used to ensure that. Both Index 1 and 2 are read as separate reads.

[sharpo]

Thanks GenoMax! That makes sense.

[Brian Bushnell]

Also, it's worth noting that Illumina base quality is reduced with each successive cycle due to phasing drift. This phasing drift is reset when a new read begins starting at a primer location. Therefore, reading the indexes independently, starting with their own primers, allows the index bases to be read without adding error to (or reducing the length of) the genomic bases.

[sharpo]

Also, it's worth noting that Illumina base quality is reduced with each successive cycle due to phasing drift. This phasing drift is reset when a new read begins starting at a primer location. Therefore, reading the indexes independently, starting with their own primers, allows the index bases to be read without adding error to (or reducing the length of) the genomic bases.

Thanks Brian! That is very useful info. Never thought of the quality aspect; but true, this is very important.

[luc]

The first indexed adapter designs were actually "in-line" indices.
Today they are only rarely used because of the already mentioned reasons and:

- the first five bases can be critical for the cluster registration and the "calibration" of the basecaller ; these sequences should be of high diversity and not low diversity sequences like barcodes. There were frequently problems with the "balancing" of these barcodes
- in-line barcode adapters are more expensive to generate since you need two complementary oligos for each index; not so for TruSeq and Nextera style adapter oligos. Thus, the latter allow also dual-indexing.

[sharpo]

The first indexed adapter designs were actually "in-line" indices.
Today they are only rarely used because of the already mentioned reasons and:

- the first five bases can be critical for the cluster registration and the "calibration" of the basecaller ; these sequences should be of high diversity and not low diversity sequences like barcodes. There were frequently problems with the "balancing" of these barcodes
- in-line barcode adapters are more expensive to generate since you need two complementary oligos for each index; not so for TruSeq and Nextera style adapter oligos. Thus, the latter allow also dual-indexing.

Thanks luc! That is very helpful information.