Hi all, I think it might be good to discuss the following: There are many pipeline proposals atm for long-read sequencing. I think especially for Oxford nanopore data, people propose pipelines using

dorado

for base calling or alignments, however the tool is mainly distributed via github (github.com/nanoporetech/dorado) with the following license (github.com/nanoporetech/dorado/blob/…/LICENCE.txt) - @James Fellows Yates / @Simon Pearce you looked into licenses recently what do you think? ONT used to deploy the software as a docker image directly, used to be semi up to date, in the past - not sure if this has changed recently… but there is for sure no conda deployment. On top ONT is deploying a set of ONT related pipelines via

epi2me

… Not sure if it might make sense to have some sort of general guidelines regarding Oxford nanopore sequencing data? E.g always start with base called long read sequencing data in bam format or so?

I like that idea

Me too

> E.g always start with base called long read sequencing data in bam format or so? I think this really depends on the pipeline. #CE9MS66BS for example needs data in fastq format, so passing in BAM would just begin with a conversion step and lead to bigger work directory sizes

@Jim Downie what about base called data instead?

Yes, I think we should always expect base-called data as input

I also think we need maybe an at-hand comparison of what we have as pipelines and what kind of features their maintainers plan to quickly react ot these proposals

and then we can finally merge all of them in sarek

Basically all ont pipelines start with the output from a separate Dorado run

Ok, I will skim the relevant pipelines later and come up with a proper proposal. I assume since this might be a bigger thingy to go the rfc route? or how to follow it up?

Probably we just need a relevant PR to the docs with the new guideline? We can have our deathmatch there instead of the deathmatch to decide whether to have a deathmatch

But i love deathmatches 😢

#C0860UN5GQ5 might be weird because methylation? Also do we have any pipelines doing direct RNA / modification reads etc? Just trying to think if anything might be doing non-standard base calling.

@Phil Ewels no, modBams would report modifications. E.g you could first basecall reads with dorado and have “unaligned” modbams and feed those in the nf-core pipelines. If i’m not mistaken PacBio has a similar option. Those would then satisfy the new base called input constrain? I think like this we could even harmonize the processing of ONT and PacBio data a bit. Since modBams or fastqs could be considered platform independent? → e.g here we had a bit of a back and forth regarding the pipeline inputs (github.com/nf-core/proposals/issues/172). But I will report later how pipelines currently do things. I think the other route could be to come up with some special

dorado

edge-case similar to cell ranger/ 10x?

I think the latter two are not very active anyway (,I think?)

#CJDV0UWH2 had a release yesterday 😉 but there fast5 are used for polishing. If I am not wrong this file format will fade out and is used by nanopolish (not sure if that’s properly maintained) later in the pipeline.

My bad 🙈 I must be thinking of a different one

We could also keep the current state as exceptions and suggest to use “platform” independent input files for long read sequencing in the future. Based on what we agree on, happy to open issues in the respective existing pipelines to ask if things could be changed in the future…

As someone who works mostly with ONT data my take is that long reads and ONT suffer from a few perspectives in nf-core land. 1. Lack of base-calling support means pipelines cannot be end-to-end and so I typically just write my own whole pipeline 2. Little consensus on best toolchain, a LOT of gradware/abandonware/non-conda tools with often very rapid release cycles makes having a pipeline that's up to date a task you really have to be on top of 3. Where a consensus of some form does exist then it's probably covered by EPI2ME so why choose a 3rd party pipeline over one ONT will give you more support debugging. 4. ONT themselves, whilst better than they once were, are still in my view hostile/bad actors in the open-source space.

..and what do you think that position should be @Arthur? 😅

I think if we are comfortable with the license and having conda not be supported then it would be fine and possibly even good to have dorado in pipelines. But it's also equally fine to say basecalling should be external.

Agree with Arthur. Only the end-to-end part is something one could discuss. Since for illumnia data we almost always start with base called data, however i see why you don’t necessarily want to have that for long-read data.