Hi @Austyn Trull and @Lara Ianov, During this week I would love to start having a dig at implementing the DNA-specific steps into

scnanoseq

. However, I'm not sure if either of you already had some ideas/plans in mind with how to best implement this? Particularly where to specify whether the input is going to be genomic or transcriptomic data. I was thinking of two potential ways: 1. Specifying the type of data and the barcode_format only as a parameter. 2. Specifying it in the samplesheet with 1-2 extra columns (genomic/transcriptomic and barcode_format). I think the second way is nicer as it also would allow mixing of transcriptomic/genomic data (assuming reference genome would be then the same). Looking forward working with you guys! Cheers, Luuk PS: I'm also available for a meeting if that is easier!

Yeah so I’ve got a couple thoughts on how we could do this: • For flexiplex, I think that can slot into both the RNA and DNA analyses, so I think we’d just add a new parameter (

--barcode_caller

or something similar) to be able to use either. We’ll just have to put some checks for BLAZE so its not used for PacBio or non-10X formats • I agree, the second way is also how I was thinking it would work. We migrate the

--barcode_format

to a sample_sheet column, and have a new column (

data_type

, not really sure on a good name) that controls the downstream analysis subworkflow switch

Ok perfect, then we're pretty much on the same level regarding this.

Hi @Luuk Harbers, if flexiplex performs better across the board and still supports the newer features of BLAZE which we do not yet have in the pipeline (e.g.: support for 5v3 for example which we will add in the future with the newer BLAZE versions), then we can certainly consider. Or at least slowly deprecate it (keep it in the pipeline for a bit with an option to run either tool and then we can make the final call to remove it as a future release). For your second point - yes indeed, forking it is the way to go and then changes would go back as a PR once you sync our newer changes on your end. That being said, we will probably want to be strategic about your changes since @Austyn Trull will be refactoring the pipeline a bit to make it more modular (move some sections into subworkflows which may aid you as you implement the DNA portion). Just an FYI so that we can hopefully coordinate to avoid replicating efforts. But no harm in starting the preliminary implementation at this point imo. One component to also think about is to add a sample dataset for the

test

and

test_full

profile. We currently have it for the RNA, but will need one for the DNA. That being said, while the

test

data needs to be very small, the

test_full

does not need to be an extremely large dataset (e.g.: in our case we use a GridION dataset from the BLAZE publication since the purpose here is to simply test the pipeline from start to finish on a sample that has not been sub-sampled down to a single chromosome). Lastly - the only note I have to add on the discussion above is that we are planning on adding support from methods such as

oarfish

which take as input a transcriptome instead of a genome (so this would fall under the case of having references which are different for RNA vs DNA). So instead of enabling both RNA and DNA to be executed together, I would probably keep them as “separate” runs so that the

--fasta

argument can be easily used for genome or transcriptome references (unless we again, move the genome component to a samplesheet but I have not seen this [I think] in other nf-core pipelines).

Thanks Lara! Once I've done some benchmarking re BLAZE/flexiplex I'll let you guys know. Will probably still be a while though. In terms of flexiplex supporting different barcoding strategy, it's incredible easy to just set up any barcoding strategy (whether its 10x commercially available or some niche strategy, doesn't really matter). What do you use now for the small test dataset? Is it actual long-read or just publicly available 10x short read transcriptomic data? For the small test set I was planning on using the available 10X multiome data, eventhough it's short read, it should still go through all steps without any issues. But for the full test we only have patient data for the scDNA (promethion), so I can't have this data publicly available sadly. Not sure yet what data would be best for this purpose. Hm gotcha, good point if you want to include

oarfish

(or any other tool that would require transcriptome). I do see that for instance

nanoseq

specifies the fasta in the samplesheet so this is definitely possible. https://raw.githubusercontent.com/nf-core/test-datasets/nanoseq/3.0/samplesheet/samplesheet_full.csv Not sure if there is a different preferred way but maybe this would then be the best way to do it to allow for processing both genomic and transcriptomic data at once. Would for sure definitely be the preferred way to do it in our case, where we will always have both genomic and transcriptomic data

For our current test dataset, we use a GridION Q20 sample published with the BLAZE paper downsampled to 5000 reads for the small test data and the full sample for the large test. So it is long-read data. Have there been any recent papers published using single-cell long read DNA? If so, we can use that data for the ‘large’ test and subsample it for the ‘small’ test, we’ll just update the citations in the test-dataset README

Ahh great! Forgot that nanoseq actually allows us to do this. Let’s think about this approach then for when the DNA support gets added. And agree with Austyn. It can be indeed hard to find long-read data for the pipeline (we had to wait until the BLAZE publication to actually have some working data that is publicly available). My suggestion would be to be on the look out for any publications between now and then (then = being the implementation) to see if anything is released. The ideal case would be to indeed have it be long-read instead of short read. If nothing is available by the time we are closer to the implementation, then we can see what the nf-core team thinks about the use of the short read data.