Closed sr320 closed 4 years ago
I'm determining counts now, but based on file sizes(the file sizes are noticeably different between each of the R1/R2 FastQ files), it's not terribly surprising that they don't have the same number of R1/R2 reads.
Thanks! makes sense. Probably should confirm files match what was provided by core. On Jan 2, 2020, 12:42 PM -0800, kubu4 notifications@github.com, wrote:
I'm determining counts now, but based on file sizes(the file sizes are noticeably different between each of the R1/R2 FastQ files), it's not terribly surprising that they don't have the same number of R1/R2 reads. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Hmmm, well, I was wrong regarding file size being an indicator for equal/unequal read counts!
The R1/R2 files have equal numbers of reads:
Sealice_F1_S20_L001_R1_001.fastq.gz
113474961
Sealice_F1_S20_L001_R2_001.fastq.gz
113474961
Sealice_F1_S20_L002_R1_001.fastq.gz
112706276
Sealice_F1_S20_L002_R2_001.fastq.gz
112706276
Sealice_F2_S22_L001_R1_001.fastq.gz
82177525
Sealice_F2_S22_L001_R2_001.fastq.gz
82177525
Sealice_F2_S22_L002_R1_001.fastq.gz
81699034
Sealice_F2_S22_L002_R2_001.fastq.gz
81699034
EDITED: Re-ordered files so that proper pairs are listed next to above/below each other.
Looking at the error message you shared and the count outputs from Bismark and my calculations, it looks like there's a problem with Sealice_F1_S20_L001_R1_001.fastq.gz
that you used for input. Maybe it didn't get fully transferred when you pulled it off of Owl?
You are correct! just ran md5...
Should have checked that first!
The files
and are at..
/Volumes/web/nightingales/C_rogercresseyi/
issue is related to consistent error seen with raw and trimmed files...