Announcement

Collapse
No announcement yet.

Comparing Cassava1.8.2 to bcl2fastq

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DrWorm
    replied
    Yeah, its mostly (if not all -- I just haven't tested thoroughly) #'s at the 3' end of reads. Seems like it shouldn't make much difference practically???

    Leave a comment:


  • HESmith
    replied
    Is the difference always a string of quality 2 ('#') at the 3' end of reads? At some point, Illumina used Q2 as an "low quality end-of-read, do not use" indicator.

    Leave a comment:


  • GenoMax
    replied
    What kind of sequencer is this data from?

    There isn't a way to directly compare bcl2fastq v.2 with CASAVA v.1.8.2 since they can't be used interchangeably (bcl2fastq v.2 can be used for all data but CASAVA can't be used for NextSeq and HiSeq 3K/4K/X data).

    Leave a comment:


  • DrWorm
    replied
    I'm told it was bcl2fastq2 2.17.

    Leave a comment:


  • kmcarr
    replied
    Which version of bcl2fastq was used? Casava 1.8.2 is really using bcl2fastq 1.8.2 for demultiplexing. Was the same "standalone" bcl2fastq version used or was it 1.8.4 or the newer 2.x bcl2fastq?

    Leave a comment:


  • DrWorm
    started a topic Comparing Cassava1.8.2 to bcl2fastq

    Comparing Cassava1.8.2 to bcl2fastq

    Hello all,

    A colleague of mine used Cassava1.8.2 and bcl2fastq to convert the same bcl file to fastq format. I was tasked with proving that the two resulting fastq files (again, the same data from the machine, just different software used to convert to fastq) are identical (i.e., the same sequence, the same quality score for each read). I noticed that some of the quality scores were indeed slightly different.

    File 1:
    @HWI-Read1_deidentified_name
    CCAAGTCTCGCTTACTTTTCATGTCATCCCGTGCCTTCTCCGAGAGGGTTCGCAGGTTCATGTTTTCAAAGATGCTAATGGACGTAGCCCAGGCCAGCGAT
    +
    0<@<DEEG<DCC<[email protected]<EEH?FHH11C/<<[email protected]=C<[email protected]@1<CG<[email protected]<CCC1<<<?C/1


    File 2:
    @HWI-Read1_deidentified_name
    CCAAGTCTCGCTTACTTTTCATGTCATCCCGTGCCTTCTCCGAGAGGGTTCGCAGGTTCATGTTTTCAAAGATGCTAATGGACGTAGCCCAGGCCAGCGAT
    +
    0<@<DEEG<DCC<[email protected]<EEH?FHH11C/<<[email protected]=C<[email protected]@1<CG<[email protected]<CCC1<<<?C##


    See the difference? Its minor, typically towards the end of the read, typically affecting poor~ish quality bases.

    Does anyone have an idea of what might cause this?
Working...
X