Hi everyone, I’m developing a new standalone proka...
# rnaseq
g
Hi everyone, I’m developing a new standalone prokaryotic RNA-seq quantification pipeline as part of my master’s thesis. The current workflow is falco → bbduk → salmon → multiqc, with a focus on prokaryotic assumptions (no splicing, no alignment by default). It differs from nf-core/rnaseq mainly in scope and defaults: prokaryote-only, simplified quant-only design, and a custom Salmon build with modified read handling at CDS boundaries. Before opening a formal proposal, I’d really appreciate any early feedback on whether this scope sounds reasonable for a new nf-core pipeline. Thank you!
i
The real judgment happens during the proposal review process, but my gut feeling is that it's not a viable addition. From your description, it sounds like this functionality can be achieved by passing a config to #CE8SSJV3N (possibly after adding a module or two). What are you proposing that is inherently incompatible or out of the scope of that pipeline?
m
On the other hand the prokaryotic route of the pipeline has been largely dysfunctional and people have encountered many issues trying to run #CE8SSJV3N on prokaryotic data. With more and more gimmicks like GPU-acceleration etc. being added to it, the complexity of the pipeline is somewhat getting out of hand. I think, the suggestion to split #CE8SSJV3N into an eukaryotic one and a prokaryotic one is worth considering. This issue is currently the best available instruction and summary of the relevant differences. It also highlights a few more tools than those you suggested, but adding these would also become significantly simpler with a dedicated pipeline. I am not a member of the core team, so can’t vote on proposals, but I think it would be a welcome boost for prokaryotic groups to get a well-maintained separate pipeline instead of being always the 2nd-class citizen in #CE8SSJV3N. It would really help to have maintainers who are themselves working on such data.
j
It would be nice if we could fix rnaseq for prokaryotic work, it comes up a lot. I do have a little flexibility right now, I might take a look as well.
OK, I whipped up a 'prokaryotic mode' for rnaseq that I think satisfies most of the discussions we've had to date: https://github.com/nf-core/rnaseq/pull/1688 I've intentionally used components we already had in the pipeline for other purposes though, using bowtie2 as the default.
Been meaning to do this for ages, thanks for the prompt! If this works, I don't think a new workflow is in order.
🙌 1
i
@Guntas Khullar in case the above works, you can always pivot in the direction of benchmarking how tools/parameters affect the final results, it's always a welcome type of study
j
I'd be interested in hearing about the modified Salmon and if the behaviour is important, if it will make it back to OG Salmon as a feature
t
While a pipeline that plays well with bacterial reference files and paradigms would certainly be of interest, my guess is that is at least as much demand for a pipeline that can be used to study host-pathogen interactions involving bacteria. There is the #C01DX1KABSR pipeline, but I honestly don't know what it can do that #CE8SSJV3N with dual (concatenated) reference files can't, and its development has been neglected, not least because it is hard to maintain software over years (typically harder than than to write a some prototype that mostly works). While adding complexity to a pipeline makes it harder to maintain, I would argue that it is still more easily maintained than _two separate pipeline_s, which would share a bunch of functionality. So while it makes perfect sense for Guntas to write a pipeline as test bed for a thesis project, I would argue that nf-core may be better served by adding functionality to #CE8SSJV3N. Guntas's pipeline project may well serve to develop and tweak important parts of that functionality, though.
i
We've had this discussion many times, and lightweight, domain-specific pipelines are generally not acceptable, as they create a huge maintenance burden compared to maintaining a domain-specific config for a larger pipeline. That said, nf-core is not a holy book of Nextflow pipelines, and anyone is free to create this type of mini-pipelines outside of the community (possibly using the template for convenience).
j
@Guntas Khullar while your pipeline might not become a standalone nf-core pipeline, I'm happy to adopt any findings that we can easily incorporate into an rnaseq prokaryotic mode, and obviously credit you on the pipeline as appropriate. 'easily' in this case means minor tweaks to logic, params etc, like I'm doing in 1688, but not additional prokaryotic analyses best left to other pipelines. Regarding the soft-clipping concern for overhanging reads from ncRNAs/UTRs absent from CDS-only indices, Salmon 1.10.3 (which we use) has built-in options for this:
Copy code
docker run --rm <http://quay.io/biocontainers/salmon:1.10.3--h6dccd9a_2|quay.io/biocontainers/salmon:1.10.3--h6dccd9a_2> salmon quant --help-reads                                                              
          
  ...                                                                                                                                                    
    --softclip                            [selective-alignment mode only (experimental)] :                                                               
                                          Allows soft-clipping of reads during selective-                                                                
                                          alignment. If this option is provided, then regions
                                          at the beginning or end of the read that do not
                                          match the reference will simply be unaligned rather
                                          than penalized.
  ...
    --softclipOverhangs                   [selective-alignment mode only] : Allow soft-clipping
                                          of reads that overhang the beginning or ends of the
                                          transcript. In this case, the overhang will simply be
                                          unaligned rather than penalized toward the mapping score.
  ...
These can be passed via --extra_salmon_quant_args '--softclipOverhangs' and for example we could enable this by default in the prokaryotic profile. I'm curious about your custom Salmon v1.5.2 build. Does it provide functionality beyond these standard soft-clipping options? If there are specific features that would benefit prokaryotic quantification that aren't in mainline Salmon, I'd be interested to understand what they are.
g
Thanks all — this has been very helpful. This is part of my MSc work, and I’ll discuss direction with my supervisor before taking anything further.
👍 1