[GenoMax]

MiSeq was designed to have minimum "user serviceable" parts (including software to run it) and this is a side effect of that convenience. In the process of simplifying the user interface they had to change several things. For most users this is the preferred solution so in general it works fine. Only in cases such as what you saw additional work is needed at times.

Since there is no phasing information available for the last base in tag that base is not considered during demultiplexing. One can use "--use-bases-mask" creatively but using a samplesheet with (n-1) bases works.

I assume you are re-running the de-multiplexing with the correct samplesheet and will let us know what happens.

[dsobral]

I assume you are re-running the de-multiplexing with the correct samplesheet and will let us know what happens.

Just run bcl2fastq with the full run and correct samplesheet.

The results show the same pattern as before: there is one "missing" sample with (almost) no data (1500-2000 reads playing with the mismatch parameter).

Ok, so I think I'm reassured the MiSeq software is doing a good (or at least decent) job. Now I'm trying to dig into the data to try and see if I can find out what may have happened... (fingers crossed). I'll also ask the sequencing facility about the cluster density: but would it affect one sample only?

Thanks a lot,
Daniel

[GenoMax]

The results show the same pattern as before: there is one "missing" sample with (almost) no data (1500-2000 reads playing with the mismatch parameter).

Ok, so I think I'm reassured the MiSeq software is doing a good (or at least decent) job. Now I'm trying to dig into the data to try and see if I can find out what may have happened... (fingers crossed). I'll also ask the sequencing facility about the cluster density: but would it affect one sample only?

Thanks a lot,
Daniel

That would almost certainly indicate that you either have a bad library for that sample (or something happened during pooling that caused that sample to drop out).

What fraction of sequences is ending up in the "Undetermined" file and how many total read you got (that should give us an idea of cluster density)?

[dsobral]

FYI, just a note on what I got so far:
The indexes from the "missing" sample are "TAGGCATG" and "TAGATCGC" (TAGGCAT-TAGATCG in the sample sheet).

Looking at the most abundant indexes in the unassigned sequences I don't see any remnants of this combination:
61972 AGGCAGATATCTCG
38880 AGGCAGATATNTCG
22973 CGTACTATATCTCG
15575 GGACTCCTATCTCG
14984 CGTACTATATNTCG
12896 TAAGGCGTATCTCG
11044 TCCTGAGTATCTCG
10075 GGACTCCTATNTCG

Well, my hopes of recovering the data this way are gone...
But at least it reassured me that it shouldn't be anything related to basecalling etc...
And I learned lots of potentially useful things (I hope)!

[dsobral]

That would almost certainly indicate that you either have a bad library for that sample (or something happened during pooling that caused that sample to drop out).

I'm inclined to think something like that happened. I'll try to see with the sequencing folks...

What fraction of sequences is ending up in the "Undetermined" file and how many total read you got (that should give us an idea of cluster density)?

The fraction that went to undetermined is roughly 5-10% (depending on mismatches in the index). What led me to think that it might be something in base-calling was it was an amount that fit with the expected size for the sample that is missing. I had 24 samples, so I expected ~5% of sequence for it...

Thanks