Thomas Sandmann’s blog - QuantSeq RNAseq analysis (1): configuring the nf-core/rnaseq workflow

[giscus[bot]]

Thomas Sandmann’s blog - QuantSeq RNAseq analysis (1): configuring the nf-core/rnaseq workflow

https://tomsing1.github.io/blog/posts/nextflow-core-quantseq-1-settings/

[MiriamAng]

Hi Thomas, first of all all thank you for the work that you did trying to establish a nice and straightforward workflow to perform QuantSeq 3' RNA-sequencing analysis using the nf-core pipeline. I am also working a lot on this and only recently (last week or so) I came across this page via the nf-core/rnaseq Slack channel. I already played around different parameters to customize the pipeline for QuantSeq 3' data, in particular to implement polyA trimming. I am working with RNA material coming from FFPE tumor tissue, which is highly degraded, and a great fraction of my reads comes with polyA tail + adapter. The main issue I faced was the removal of both adapter and polyA using Trimgalore. Indeed, while with Cutadapt I was able to implement it (specifying two adapter's sequences and the argument -n 2), within the nf-core pipeline Cutadapt is not customizable but only Trimaglore is. Therefore I decided to perform quality and adapter trimming on raw reads using Cutadapt through an external shell script and provide the adapter trimmed reads in input to the nf-core pipeline to undergo poly A removal with Trimgalore. Coming across your blog, it has come to my attention that it is possible to perform polyA removal also with STAR, which would save me from using the external shell script. I therefore performed a trial where I compared my configuration (i.e. external script for adapter and quality trimming and polyA removal with Trimgalore) with the one mentioned here (i.e. adapter and quality trimming with Trimgalore and polyA removal with STAR) but results are not comparable. In particular, in terms of % of aligned reads, which is the parameter that I am monitoring, with the second configuration I obtain a lower % of aligned reads (e.g. 65% vs 80% obtained with the first configuration). From my side the main issue is that I am not sure of how STAR performs polyA removal and how the number of "A"s specified through --clip3pAdapterSeq influences the trimming. It would be great if we could confront each other to find the final configuration that best suits QuantSeq 3' data! Thank you! Miriam

[tomsing1]

That's really good to know, thanks a lot for describing this issue! I have not evaluated the pros / cons of using STAR for adapter trimming, because our original (non nf-core pipeline) also relied on STAR for this step. It would definitely be good to understand if I have been throwing out good reads, as the lower mapping rate you observed would suggest. Perhaps we can take this discussion to the nf-core/rnaseq slack channel, to get input from others as well? I suspect that a tools that supports adapter-trimming & polyA trimming (without the need to run it twice) like fastp might be useful. (And it might also offer speed advantages.) Let's bring up your concerns via slack?

[MiriamAng]

I tried to ask Alex Dobin (alexdobin/STAR#1774) to have more info on the behavior of the parameter --clip3pAdapterSeq. In particular, it would be nice to know whether the number of nucleotides trimmed is exactly as the number of As specified or not (e.g. if we have a read tail with 18 As and we only specify 10 in --clip3pAdapterSeq, does it mean that 8 will remain there? If so, this can explain the lower alignment rate). Unfortunately on the STAR manual, as well as on the web, I was not able to find anything that answers my question.
I totally agree in bringing up our concerns via slack, I think it would be really helpful trying to solve this issue and finally have an agreement on the best way to proceed for QuantSeq 3’ data!

[tomsing1]

Thank you for pinging Alex Dobin, hopefully he will reply and shed light on what the argument means exactly! Let's continue on slack!