It shows thar coverage is always 0, but I can't figure out why this happened. Can you help me ?
Hi, did you checked your bam file ? You can run "samtools flagstat" on it to check the number of reads mapped to the reference.
I have just used haplotypecaller to call variants in the contig tig00000488|arrow , and the result contains many variants. It means that there are a lot of reads mapped to the contig indeed, opposite to the coverage 0 showed in pilon log. So , I think my bam file is ok. And I will also run "samtools flagstat" on it to check the number of reads mapped to the reference then.
I think I have found the reason. I changed the parameter of bwa when mapping Illumina data to the draft assembly and this time pilon worked.
You can see that I removed the parameter -M and -P from the command. M means marking shorter split hits as secondary (for Picard compatibility), and P means in the paired-end mode, performing SW to rescue missing hits only but do not try to find hits that fit a proper pair.
Though I have solved the problem, but I can't figure out why this happened. Any one can help me ?
If you have time you can try to map with the -M option only, and then with the -P option only, to see which one of the two (or the two together) is causing the issue.
I remember that for pilon the bams need to be "sorted in coordinate order and indexed" (https://github.com/broadinstitute/pilon/wiki/Requirements-&-Usage), but I guess pilon would just throw an error instead of giving 0 coverage for unsorted bams.
Thank you for your reply. Following your advice , I map with the -M option only, and then with the -P option only, and I found that -P is causing the issue.