Hi @Bilal Asser Hi <!here>, I’ve been investigating a possible issue in the phylogeny workflow on

dev

. The workflow passes the joint cohort VCF from

GATK_MOI

into

PHYLOGENY

, pairing it with each WGS sample’s metadata. However,

BCFTOOLS_CONSENSUS

does not explicitly select the corresponding sample. In a controlled test with BCFtools 1.23.1, omitting sample selection produced an ambiguity-coded consensus when samples had different genotypes. This suggests that the workflow may not be generating truly sample-specific consensus sequences. I haven’t changed anything yet. Does this match the intended design? If so, I’d be happy to investigate a fix and add a regression test.

hello Clement, I think this was the same problem I already pointed out in github.com/nf-core/pathogenepidemiology/issues/50, @Debjit Pramanik should be already working on it

Thanks, Victor. I've now read issue #50 and confirmed the same behaviour in a small controlled test with BCFtools 1.23.1: without sample selection, different sample genotypes can produce an ambiguity-coded consensus. I see that Debjit has taken the issue. I'll avoid duplicating the implementation. If useful, I'd be happy to help validate the fix or test the per-sample consensus behaviour.

Hi @IGIRANEZA CLEMENT, @Víctor Manuel Duarte Rute, thanks both, and thanks Clement for not duplicating it. Yes,

--sample

fixes the genotype selection. I tested it in the pipeline's bcftools container (1.23.1) with a two sample VCF where the samples carry different alleles. Without

--sample

, both consensus FASTAs were identical, with IUPAC codes (R/Y) mixing both samples' genotypes. With

--sample <id>

, each FASTA has only its own sample's alleles. The fix is one

ext.args

entry for

BCFTOOLS_CONSENSUS

in

conf/modules.config

, plus an nf test regression test that fails without it and passes with it. I've rebased it onto today's

dev

and will open the PR today. The duplicate FASTA names Clement hit in CI are a separate problem that

--sample

doesn't solve.

bcftools consensus

keeps the reference contig names as headers, so every sample's FASTA has the same names (e.g.

>MT192765.1

for both samples in my test), and

collectFile

concatenates them into one file with duplicates. With Plasmodium it's also one record per contig per sample. This is the multi contig follow up that #50 lists as out of scope. @IGIRANEZA CLEMENT, would you like to take that part? It needs a decision on how to name and join each sample's contigs into one sequence before MAFFT/IQ-TREE. It would also be really helpful if you could run my PR on your multi-sample CI data once it's up, to validate the per-sample consensus.

Thanks, Debjit. I'd be happy to help with both. I'll first test PR #68 using my multi-sample Plasmodium data and report the results. After that, I can investigate the multi-contig issue and discuss the expected FASTA structure with you and Victor before proposing a solution.