New pipeline: nf-core/shallowseq

[brandenjlynch]

Pipeline title/name

shallowseq

Keywords

genomics, cancer, shallow whole-genome sequencing, copy-number

What is it about?

A pipeline for processing shallow whole-genome sequencing data, including alignment, duplicate marking, and QC, followed by downstream generation of relative copy-number and estimation of absolute copy-number. The pipeline is optimized for shallow sequencing and formalin-fixed paraffin-embedded (FFPE) samples.

Please provide a schematic diagram of the proposed pipeline

What would a minimal first release of this pipeline include?

A minimal first release would include read trimming with Trimmomatic, alignment with bwa-mem, duplicate marking with Picard MarkDuplicates, QC with FastQC and MultiQC, relative copy-number estimation with QDNAseq (and/or WisecondorX, IchorCNA), and absolute copy-number estimation with Rascal/ACE (or an equivalent method).

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?

There are no existing pipelines which are optimized for processing shallow whole-genome sequencing data from patient tumors, especially data obtained from FFPE samples, which are generally of poor quality compared to fresh or frozen samples. FFPE samples are very common clinically and shallow sequencing is cost-effective, making it desirable to be able to process these samples in a robust way. While existing pipelines like sarek or oncoanalyser can call variants, including copy-number variants, they leverage tools that require deeper sequencing for robust results. For example, tools like ASCAT require allele-specific information, which is of poor quality for shallow sequencing owing the lack of depth supporting estimated b-allele frequencies. The proposed pipeline will employ tools that are optimised for the limitations imposed by shallow sequencing, such as QDNAseq and WisecondorX.

Who would be interested?

This pipeline would be of interest to researchers and clinicians in oncology that would like to use cost-effective shallow whole-genome sequencing to profile the copy-number landscape of their samples.

What has been done so far

The pipeline is already complete (meeting & exceeding the minimum viable description above), albeit without being totally compliant with nf-core guidelines. Some refactoring will need to take place in order to make it nf-core compliant.

URL to existing work (if applicable)

https://github.com/Huntsmanlab/swgs-processing-pipeline

Are there any similar existing nf-core pipelines?

sarek, oncoanalyser

[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, @camlloyd, @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, @camlloyd, @vagkaratzas, @sateeshperi, @jonasscheid, @famosab, @nictru, @itrujnara, @LouisLeNezet, @Joon-Klaps, @jasmezz, @Felix-Kummer, @sofstam, @nvnieuwk

[christopher-hakkaart]

Hi @brandenjlynch, thanks for submitting a proposal!

There is a balance between adding to existing pipelines to add value and not overfilling a pipeline, which can cause undue complexity. To start, I'll ask @maxulysse and @FriederikeHanssen, who are most familiar with Sarek, to comment on this. Also, could you please share an accessible link to the swgs-processing-pipeline pipeline for viewing?

[brandenjlynch]

Hello @christopher-hakkaart, @maxulysse, and @FriederikeHanssen, thank you for looking at our submission! I will make the the pipeline repository visible in the next day or so, once I finish merging some changes. Please let me know if you have any questions!

[christopher-hakkaart]

Sounds good - thanks @brandenjlynch

[brandenjlynch]

Hi @christopher-hakkaart, the repo link should be visible now! Let me know if you have any questions as you go through it.

[jfy133]

I agree there seems to be quite a close overlap with sarek (To my knowledge anyway), which makes me wonder to what extent could there be a predefined set of configuration options for this particular type of sample in sarek itself?

But if the experts agree this should be a separate proposal, I will say the name is not specific enough - any biological sample in any domain can be shallow sequenced ;) so in the meantime other name suggestions will be welcome

[FriederikeHanssen]

I am not categorically opposed to this becoming a separate pipeline to contain Sarek's scope. That being said, the preprocessing looks nearly identical aside from the "Azure" process and using Trimmomatic instead of Fastp. What does "Azure" do, is there an advantage to using Trimmomatic over Fastp?

What I am wondering is if there is an option to either use this opportunity to implement the preprocessing as a shared subworkflow between the pipelines or implement the shallow data-specific subworkflow in nf-core/modules and import it into sarek.

How does this data fare on Sentieon and parabricks tools for the preprocessing? Does it require specific parameters?

[brandenjlynch]

Haha fair point @jfy133! Perhaps a name closer to 'swgs' or 'lowpasswgs' would be more precise!

To address your other point and that raised by @FriederikeHanssen, the pre-processing is overall quite similar to Sarek, in that it is more or less the standard processing of WGS data. The Azure process pulls data stored in Azure storage if desired, rather than local files.

I am not aware of huge differences between Trimmomatic and Fastp. Some of the tools in the sWGS space (ex. QDNAseq) were originally designed for short ~50 bp sequencing, so we provide the option to crop reads to that length as well, if desired, which is handled by Trimmomatic. If one lacks a panel of normals and wants to use the built in 50bp-derived panel data (bin annotations) in QDNAseq, then cropping would make sense to keep things as similar as possible.

I could see implementing the preprocessing as a shared subworkflow -- I think that would make a lot of sense actually. It would also be possible to add the shallow specific subworkflow (for the tools) to Sarek. Sarek does seem to have a pretty extensive list of tools already, and I can't see most people running them at the same time as other WGS-focused tools in Sarek, since most of those tools are of limited value for sWGS. That being said, I think either could work. It really just depends on whether you want to increase the scope of Sarek or not I think.

I can't speak how this data fares on Sentieon and Parabricks tools as I haven't used them for preprocessing. There are a couple specific parameters but nothing too unusual; optional read cropping, keeping overlapping reads (i.e., short insert), because FFPE often has short fragments.

[itrujnara]

Sarek is already complicated enough as it is, so I believe a separate sWGS pipeline is appropriate. However, I see one necessary condition, already mentioned in this discussion: the preprocessing subworkflow(s) should be shared with Sarek to avoid code duplication, and the development here should be focused on the sWGS-specific annotation part.

[brandenjlynch]

Hi @itrujnara, that makes sense and is something we would be amenable to. I think we should largely be able to use the Sarek pre-processing workflow as is, except that it would be nice to have the option to crop reads as I described above.

Edit: another important feature of our processing is the ability to handle both single-end and paired-end reads.