Closed mclaugsf closed 6 years ago
I see that all the read IDs it does this to don't have sequence or quality scores i.e.:
ubuntu@ip-10-0-0-200:/efs/Inputs/human-datasets/ASV_0009$ gunzip -c ASV_0009.Tumor.RNA.CeGat.R1.fastq.gz | grep HISEQ:103:H3KNHBCXX:1:1101:15244:7826 -A4
@HISEQ:103:H3KNHBCXX:1:1101:15244:7826 1:N:0:GTGCTT
+
@HISEQ:103:H3KNHBCXX:1:1101:15148:7833 1:N:0:GTGCTT
seqtk sample turns this into:
ubuntu@ip-10-0-0-200:/efs/Inputs/human-datasets/ASV_0009$ grep "HISEQ:103:H3KNHBCXX:1:1101:15244:7826" blah1.fastq.gz -A4
>HISEQ:103:H3KNHBCXX:1:1101:15244:7826 1:N:0:GTGCTT
@HISEQ:103:H3KNHBCXX:1:1101:2877:8014 1:N:0:GTGCTT
TTTTTCTTTCTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
+
Is the FASTQ spec being broken by having a read ID for a read that doesn't exist in the original input?
Same problem occured a few days ago: https://github.com/lh3/seqtk/issues/109 , but it' hard to change in near future. You may use seqkit (>=v0.8.0) for now, which just fix this.
Thanks! I thought it was a bug.
When I run seqtk sample some of the read IDs are getting the "@" character swapped out for a ">".
There are no reads which match ">HISEQ" in the input. But they come out like this w/seqtk:
And if I take the first one out of the input file it doesn't have the leading ">" character:
Happening in version 1.2-r94 and I also tried 1.2-r102-dirty