skoren
commented
4 years ago You can bin the HiFi data in a stepwise fashion, this is the only currently supported way to bin HiFi data. Typically, we don't bin HiFi data at all as we can separate haplotypes and preserve large phase blocks w/o trio information using it. You could also try this strategy (just assemble the data) followed by purge_dups.
If you do want to bin, there is a way to overwrite the threshold manually. Edit the splitHaplotype.sh file to remove the statistics file and change it to an int, e.g. -H ./0-kmers/haplotype-O157.meryl ./0-kmers/reads-O157.statistics ./haplotype-O157.fasta.gz would become -H ./0-kmers/haplotype-O157.meryl 5 ./haplotype-O157.fasta.gz. Remove haplotype.log and any fasta.gz files and re-run splitHaplotype.sh by hand.
Lastly, can you share the statistics files to see why such a high threshold was selected? You should be able to attach them to the issue.
egoltsman
Hi Sergey, This is in regards to Canu v. 1.9 and the trio binning workflow. I could confirm with my local install that it works as described in the documentation when the F1 reads are provided with the -pacbio-raw option. From reading issue #1559 it seems like it's possible to use HiFi (CCS) reads instead, (although the user did this in a stepwise fashion). Is this a supported workflow, or are we jumping the gun here? When I execute the same set of commands given in the documentation but with
-pacbio-hifior-pacbio-correctedinstead of -pacbio-raw, then no haplotyping is performed.So the best thing I could try is run the haplotyping step alone, pretending that the long reads are of CLR type (in case that even matters at this stage), and then running two separate assemblies on the binned reads as -pacbio-hifi. That seemed to work, but the reads didn't get separated, with 98% of the reads piling up in one haplotype. Combing through the outputs, the kmer distributions look good to me for both parents, with distinct heterozygous and homozygous peaks in each. But in the file splitHaplotype.000001.out there's a line that suggests that for one of the haplotypes the kmer selection picked the depth cutoffs incorrectly:
Naturally, very few kmers got selected for this bin, and so the binning largely failed. Going by the histogram, the frequency peaks for this parental data set were at 14x and 28x for the hetero- and homozygous kmers, which seems ok. For some reason, the program skipped past them and picked the low threshold way out in the outliers.
Has this been reported before, and is there a way to force/override the depth thresholds at this step?
Thank you in advance!