alexdobin
commented
4 years ago Hi @Yashu0106
there is nothing suspicious in the Log.final files. Since SE read1/2 map with pretty much the same rate as PE, it's not a problem with pairing or one of the reads. You can try to compare this sample Log.final with the "good" samples to see if anything else besides the mapping rate is different. Another suggestion is to take a few unmapped reads and BLAST them - this will check for contaminations and incomplete assembly.
Cheers Alex
Hi Alex, I have read a few issues that had the similar problem, but still couldn't solve mine following the recommended methods. I have 30 samples and all of them had uniquely mapped reads% at around 90% except for one, which has only reached about 74%. 23% of the reads were mapped because they were too short.
I trimmed the fasta files and examined fastqc report of this sample, the quality report looked perfectly fine and was of no difference with my other 29 samples' fastqc report. I then ran the paired-ended fasta files separately according to your suggestion in the other post. The mapping rate didn't increase, for both separately-ran files they were around 74%. Could you help me to take a look at the log.final.out for the trimmed_fasta files, and alignment of separated fasta file? I don't know what else I could try to solve this problem without risking chance of false alignments.
NEW_EL31_152LLog.final.out.txt PAIR1_EL31_152LLog.final.out.txt PAIR2_EL31_152LLog.final.out.txt