Hi
@TO, thank you and that’s a great question. A lot of the answers in terms of details on performance etc. will actually be present in the scnanoseq pre-print (we are trying to get this out asap!). But here is a summary of some of the unique aspects of scnanoseq:
• Several layers of QC: we find this to be critical in scRNA analysis due to the nature of single-cell/nuclei secondary data analysis. We aimed to ensure that filtration rates and levels were very transparent while still providing the option of skipping certain QCs if the users choose to do so (although we don’t recommend).
• Quality and length trimming option: we find that many pipelines do not offer this feature. We ensured this is an option through NanoFilt to allow users to have control over the min. length and quality of Oxford sequencing, especially considering that we do still find reads have low Phred quality scores.
• We leverage many off-the-shelf tools and the nf-core framework which allows for high configurability of each process by the user. This is a critical point that we chose to pursue to give users as much flexibility as possible with methods that have been well quantified and reviewed in the academic community including BLAZE and IsoQuant as examples. For instance, while we have set sensible defaults in IsoQuant for gene and transcript-level quantification, IsoQuant provides additional functionality (e.g.: de novo transcript discovery) which can be enabled by a custom configuration at this stage in scnanoseq.
• Ability to provide a custom whitelist. While the “default” 10X whiltelists (e.g.: “3M-february-2018", “737K-august-2016”) are expected to be used in higher rates, this parameter enables users to implement whitelists that may not yet be available in the pipeline including edge cases such as the following study as an example:
https://www.nature.com/articles/s41467-023-39813-7)
• As part of the nf-core framework, our pipeline offer support for conda in addition to Docker and Singularity (this is not true to other pipelines available)
• Run times are comparable to other pipelines we have seen (e.g.: both scnanoseq and wf-single-cell have had great improvements through their developments in the run time). Currently, the process that takes the longest run time is IsoQuant, and our past discussions with the author point towards additional support in the near future which will continue to improve run times (we also have an alternative approach in mind which can further aid this as well for IsoQuant which we may implement in a future release).
This is a brief summary; the pre-print will contain details on the validation and the pipeline benchmark as well. Hope this helps!