Support polyploid assembly

[prototaxites]

Is your feature request related to a problem? Please describe

Currently the assembly always assumes that the output of Hifiasm is diploid and split across two assembly files, hap1/hap2 or pri/alt.

It would be good to be able to handle more haplotypes per assembly. This will probably require concatenation of haps at various points, and the designation of a "primary" haplotype.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

[purvanshjoshi]

Hi @prototaxites, thank you for opening this feature request and describing the current limitation around assuming a diploid Hifiasm output (hap1/hap2 or pri/alt). I am interested in working on extending the pipeline to support assemblies with more than two haplotypes.

I've reviewed the current implementation and propose the following approach to handle multiple haplotypes while maintaining compatibility with existing downstream logic:

Strategy: Primary + Merged Alternate

The core idea is to identify one haplotype as "primary" (hap1) and concatenate all remaining haplotypes into a single "alternate" (hap2) assembly. This preserves the existing "primary vs alternate" logic in downstream steps while supporting any number of input haplotypes.

Key Changes:

1. Splitting Logic Update

• Change from explicit matching (h2tg, atg, hap_) to inverse logic
• Define "alternate" as "everything that is NOT primary"
• Primary patterns remain: ^h1tg|^ptg
• This approach is more robust for variable haplotype counts

2. Subworkflow Modifications

• File: subworkflows/local/raw_assembly/main.nf
  • Import CAT_CAT module for concatenation
  • Update ch_assemblies_fasta logic:
    • Identify primary file (matching hap1.p_ctg.fa or p_ctg.fa)
    • Identify alternate files (all other hap*.p_ctg.fa or a_ctg.fa)
    • Add branching logic:
      • If single alternate file: pass through
      • If multiple alternate files: merge using CAT_CAT into single hap2 file
    • Emit hap1 and hap2 (merged alternates)
  • Update versions mix

3. Configuration Updates

• File: conf/modules.config
  • Update SEQKIT_GREP_SPLIT_HAPS configuration
  • Change ext.args for hap2 to use inverse matching (-v) against primary patterns (^h1tg|^ptg)
  • This captures all non-primary sequences effectively

** Your Review Required:**
The splitting logic change is critical - it assumes that hap1 (primary) patterns (h1tg, ptg) are well-defined and exhaustive. This needs validation from your team to ensure it correctly identifies all primary assembly sequences.

Before I start implementing these changes, could you please advise if this approach aligns with your expectations for polyploid support? Are there any specific considerations or edge cases I should be aware of regarding the primary/alternate designation?

I am happy to begin with a small, incremental PR and iterate based on your feedback.

[prototaxites]

Hi @purvanshjoshi,

Thank you for your interest in the pipeline!

This is a feature that we are still exploring internally at Sanger, where we are developing the protocols for the pipeline through regular RND work. We have not yet settled on an approach for polyploid assembly, and currently there is no real tooling in place that would produce more than two haplotypes from any assembly that would require that we change the pipeline code at this stage.

We are also currently in the process of re-factoring the pipeline, which means that any PRs against dev are currently unlikely to remain intact once the refactor has been merged.

You are more than welcome to work on this feature (and if you haven't, please see our contribution documentation here: https://github.com/sanger-tol/genomeassembly/blob/dev/.github/CONTRIBUTING.md), but given the above please be aware that it will be some time before we know how we want to approach this aspect from a bioinformatics perspective, and then decide on an implementation in code.

[purvanshjoshi]

@prototaxites
Thank you for the clarification and context. I’ll treat any work on polyploid support as exploratory and non-blocking, and I’m happy to prototype ideas in a draft PR that can inform your future design once the refactor and bioinformatics strategy are more mature.