New pipeline: nf-core/swgsrelate

[thomasisensee]

Pipeline title/name

swgsrelate

Keywords

genomics, relatedness, lcWGS, variant calling, GATK, bcftools, BQSR, population genetics, non-model organisms

What is it about?

The pipeline provides a complete workflow for estimating pairwise relatedness in diploid eukaryotic organisms using low-coverage whole-genome sequencing (lcWGS) data.
It performs read preprocessing, base quality score recalibration (BQSR), variant calling (using both GATK and bcftools), and multiple complementary relatedness estimation approaches.

Originally developed for wild guineafowl populations, the workflow is generalizable to any diploid species with a reference genome but without high-confidence variant resources. The analytical logic follows the general approach described in Snyder-Mackler et al. 2016, adapted for low-coverage whole-genome sequencing (lcWGS) data in non-model organisms.

Please provide a schematic diagram of the proposed pipeline

A schematic overview will be added once the new DSL2 workflow structure is finalized.
At present, the pipeline conceptually consists of four modular stages:
(1) preprocessing, (2) base quality score recalibration (BQSR),
(3) variant calling, and (4) relatedness estimation.

I confirm my proposed pipeline will follow nf-core guidelines. Most importantly, my pipeline will:

• be built with Nextflow.
• pass nf-core lint tests and use standardized parameters.
• be community-owned and developed within the nf-core organization.
• open source under the MIT license with proper credits and acknowledgments.
• have a descriptive, all lowercase, and without punctuation name.
• use the nf-core pipeline template and predominantly use official nf-core modules.
• focus on a specific data/analysis type with appropriate scope.
• have properly maintained documentation.
• be bundled using versioned Docker/Singularity containers.

Why do we need a new pipeline?

An older, non–nf-core, DSL1 version of this workflow already exists, but:

• It predates nf-core and modern Nextflow DSL2 module/subworkflow standards.
• It uses a monolithic structure that prevents modular reuse and containerized reproducibility.
• It was licensed under GPLv3, which prevents integration into nf-core (MIT license).
• Practically all code must be rewritten from scratch to meet nf-core style and configuration standards.

The new pipeline will therefore be a complete reimplementation, retaining only the workflow logic while adopting the nf-core structure and community standards.

Who would be interested?

• Population and evolutionary biologists working with low-coverage WGS data on non-model species
• Research groups estimating kinship and relatedness in field-collected samples
• Core sequencing and bioinformatics facilities supporting such projects
• Comparative genomics researchers using GATK, bcftools, ANGSD, and related tools in lcWGS contexts

What has been done so far

• A fresh nf-core template repository (DSL2, MIT) has been initialized.
• Early modularization of the preprocessing and variant-calling stages is in progress.
• The previous GPLv3-based DSL1 workflow has been reviewed for conceptual structure but will not be reused in code form.

URL to existing work (if applicable)

https://github.com/GiselaHKopp/sWGS_Relatedness_Pipeline_v1

Are there any similar existing nf-core pipelines?

No response

[nf-core-bot]

Approval status: ✅ Approved

Required approvals: Either 2 core team members OR 1 core team member + 1 maintainer

Review Status	Team members
✅ Approved (Core)	@nvnieuwk, @jfy133
🕐 Pending (Core)	@ewels, @maxulysse, @mribeirodantas, @mashehu, @JoseEspinosa, @mirpedrol, @FriederikeHanssen, @kenibrewer, @edmundmiller, @sateeshperi, @FranBonath, @christopher-hakkaart
🕐 Pending (Maintainer)	@pontus, @maxulysse, @lpantano, @pinin4fjords, @mashehu, @JoseEspinosa, @mirpedrol, @GallVp, @FloWuenne, @matthdsm, @FriederikeHanssen, @adamrtalbot, @mahesh-panchal, @jfy133, @atrigila, @prototaxites, @ramprasadn, @edmundmiller, @luisas, @SPPearce, @vagkaratzas, @sateeshperi, @jonasscheid, @famosab, @nictru, @itrujnara, @LouisLeNezet, @Joon-Klaps, @jasmezz, @Felix-Kummer, @sofstam, @nvnieuwk

[nf-core-bot]

Approval status: 🕐 Pending

Required approvals: Either 2 core team members OR 1 core team member + 1 maintainer

Review Status	Team members
🕐 Pending (Core)	@ewels, @maxulysse, @mribeirodantas, @mashehu, @JoseEspinosa, @mirpedrol, @FriederikeHanssen, @kenibrewer, @jfy133, @edmundmiller, @sateeshperi, @FranBonath, @christopher-hakkaart, @nvnieuwk
🕐 Pending (Maintainer)	@pontus, @maxulysse, @lpantano, @pinin4fjords, @mashehu, @JoseEspinosa, @mirpedrol, @GallVp, @FloWuenne, @matthdsm, @FriederikeHanssen, @adamrtalbot, @mahesh-panchal, @jfy133, @atrigila, @prototaxites, @ramprasadn, @edmundmiller, @luisas, @SPPearce, @vagkaratzas, @sateeshperi, @jonasscheid, @famosab, @nictru, @itrujnara, @LouisLeNezet, @Joon-Klaps, @jasmezz, @Felix-Kummer, @sofstam, @nvnieuwk

[nvnieuwk]

I see quite a lot of overlap with the Sarek or raredisease pipelines. In what way does this proposal differ from these pipelines? Is there a reason why the relatedness modules couldn't just be added to those pipelines?

[thomasisensee]

Thanks a lot for the suggestion! Integrating this into an existing pipeline like sarek or raredisease would definitely be great in theory. But I have some doubts that it would work easily in practice.

The workflow we’re developing is aimed at low-coverage whole-genome sequencing (lcWGS) data from non-model species (e.g., guinea fowl), without any known variant resources such as dbSNP. It uses an iterative BQSR / joint-genotyping strategy and tools for relatedness estimation (READ, lcMLkin, NgsRelate, PCAngsd).

While the preprocessing steps (QC, mapping, deduplication, BQSR) are very similar (basically identical to what Sarek does) the rest of the pipeline differs a lot more than it might seem. As I understand, sarek and raredisease are tuned for high-coverage (mostly) human data, focusing on variant discovery and annotation with existing reference panels and confident genotypes.

Of course we’d definitely reuse nf-core modules where possible. Even though I'd be happy to be convinced otherwise, I currently believe it makes more sense to keep this as a dedicated lcWGS / relatedness pipeline.

[nvnieuwk]

Sounds good to me in that case!

/approve

[thomasisensee]

Could you advise on the preferred procedure for publishing/sharing/reuse of subworkflows within nf-core? For instance, we could make direct use of Sarek’s BAM_VARIANT_CALLING_MPILEUP. Would it be possible to upstream this and others as shared nf-core subworkflows?

Our intention is definitely to stay aligned with the community and maximize code reuse, but within a focused pipeline tailored to lcWGS relatedness estimation.

[mashehu]

If you want to reuse local sarek subworkflows, you should move them over to the nf-core/modules repo and then install it through that.

[jfy133]

I'm also inclined to approve but I would like to see more details

A schematic overview will be added once the new DSL2 workflow structure is finalized.
At present, the pipeline conceptually consists of four modular stages:
(1) preprocessing, (2) base quality score recalibration (BQSR),
(3) variant calling, and (4) relatedness estimation.

We don't need a fancy pants metro map or anything at this stage @thomasisensee , it can also be a pen and paper diagram mostly with the names of the tools etc. you would be using.

If you can provide this I will probably be comfortable giving the approval :)

[thomasisensee]

Thanks a lot for the feedback!

I’ve just added three images that should make the structure clearer:

A hand-drawn overview schematic showing the full workflow and how the main stages connect:

An automatically generated DAG for the preprocess subworkflow:

Another DAG for the variant bootstrapping subworkflow:

The bootstrapping subworkflow corresponds to steps (2)–(4) in the hand-drawn overview. It can be executed multiple times in series (usually 2–5). The idea is that each round takes the previous round’s output as input, allowing the workflow to bootstrap its own high-confidence variant set. To my knowledge, that iterative BQSR/variant calling approach doesn’t currently exist in any nf-core pipeline.

Then, there will be the relatedness estimation subworkflow with several tools for low-coverage WGS data (e.g., ngsRelate, READ, BREADR, and possibly others), which again isn’t represented in existing nf-core pipelines as far as I know.

Used nf-core modules:

• bcftools:
  • call
  • concat
  • index
  • isec
  • mpileup
  • sort
  • stats
• bwamem2:
  • index
  • mem
• fastp
• gatk:
  • addorreplacereadgroups
  • applybqsr
  • baserecalibrator
  • createsequencedictionary
  • gatherbqsrreports
  • genomicsdbimport
  • genotypegvcfs
  • haplotypecaller
  • markduplicates
  • mergevcfs
  • selectvariants
  • variantfiltration
• gawk
• mosdepth
• preseq:
  • ccurve
  • lcextrap
• samtools:
  • convert
  • faidx
  • index
  • merge
• spring/decompress

Local modules:

• angsd/ngsrelate
• gatk/analyzecovariates
• more relatedness estimation modules…

And for context: I’m a research software engineer embedded in this collaborative project, so my background is more on the software/HPC side than biosciences, but I’m working closely with the domain experts on the logic and validation.

Hope these visuals help!

[jfy133]

Thanks @thomasisensee ! I'm going to ping a bunch of variant calling/population genomics people in the community for their thoughts/opinions

@maxulysse @FriederikeHanssen @TCLamnidis

[FriederikeHanssen]

@maxulysse @TCLamnidis @FriederikeHanssen to reply!!!!!!!!

[TCLamnidis]

This is an interesting approach, and not something I've seen done before.
As far as the processing goes, and the specific use case, I can see a use case for the pipeline, and think it would fit in nicely within nf-core.

I expect the naming of the pipeline to be a point of contention among the nf-core peeps, as swgsrelate is not particularly informative.

[thomasisensee]

Thanks for your feedback @TCLamnidis! The current pipeline name is a placeholder (shallow whole genome relatedness) and we intent to change it. Some candidates:

glare: Genotype Likelihood And Relatedness estimation
genrel or genrelate: GENotype and RELatedness estimation
genorel: genomic relatedness
kinest: kinship estimation
lowkin: low-coverage kinship
shallowkin: shallow (whole-genome sequencing) kinship