Should I treat different assemblies of a sample as different "haplotypes"?
I have sequencing data (HiFi) from 8 different human individuals. In an attempt to explore the effects of different assemblers, I assembled these data with 3 different assemblers (Hifiasm, Flye, Shasta). The thing is that I don't want to choose the "best" assembly (even though hifiasm > shasta > flye). In contrast the idea is more like to take uncertainty into account. So if, for example, I'm building a pangenome graph from those samples, do you think it would make sense to do so using all 3 assemblies of each sample as 3 different "haplotypes"? Is it something that you would do? Would you, instead do something else?
• 801 views
•
link
updated
by
Istvan Albert
•
written
by
Panos
•
written
by
Panos
0 answers
No answers yet.
Log in to answer this question.
More posts like this
-
Constructing a bread wheat pangenome graph using PGGB: per-chromosome vs. whole-genome approach and…
written by Sony Nguyen •
-
Several questions for genereating human genome assembly
written by tungsega •
-
Fungal Genome Assembly: In a messed up situation
written by SomeOne •
-
How to interpret and filter vg call output VCF
written by Tobias •
-
Best practice to merge per sample variant calls from personalized pangenomes
written by Tobias •
-
GBWT Construction Error: "Sources X and Y both have node Z" When Building GBZ from GFA
written by Sauers •
-
Limma covariates treatment is changing my significance results
written by ijarne •
-
Challenges in Variant Calling and Genotyping with Short-Read Data Mapped to a Pangenome Graph: Seek…
written by Kyran •
-
RNA Sequencing and Vg pan -transcriptome build
written by kcarey •
-
Hardware requirements for de novo assembly of a small plant genome (<1 Gb) with PacBio HiFi
written by antmantras •
Treating each as individual haplotypes seems reasonable in a pangenome graph (and generally an interesting analysis pipeline). You could use it at least to check whether it is helpful to add additional assemblies to the graph by checking how each addition changes things like mapability of raw reads or amount of unique material in the graph.
I would say each assembly reflects the algorithm more than the data.
Each assembler makes several assumptions and applies various heuristics. You can test that out by assembling a simulated, but known data and see what they generate.
Just to note; I think the use of the term haplotype here was just using the technical convention from genome-graph builders, where you are allowed to add several assemblies per sample for each haplotype, hence the double quoted "haplotypes". So I think that the idea is to take advantage of this feature to take a sort of aggregate assembly.
I am not sure I understand what this is actually saying...I think it is fair to say that an assembly is a reflection of both the data and the algorithm (one more than the other in some cases maybe?), Regardless I think the idea is to take advantage of how different assemblers handle better or worse different complex regions in order to get a more complete image of the genome.
I am not sure how much would be learnt from simulated datasets considering the impact of variation in read lengths, technologies, coverage, sample etc etc etc. It seems safer to just compare the actual output.
I was using the word haplotype in the biological sense, as a block of DNA transmitted together from a single parent. I should have probably mentioned that.
What I was trying to say is that the differences in assemblies are likely primarily about the heuristics and algorithms.
If the OP thinks one assembler is already better than the other, there may be no need to work with a worse version just to account for the fact that in some region this worse assembler turns out to be locally better.
As for testing, I meant to run these aligners on simulated data with similar properties, then gauge how different the results are. Sometimes these issues become clearer when you know the ground truth.