update scRNAseq workflow about snakepipes HOT 10 CLOSED

Which changes you mean?

from snakepipes.

Any updates present in current develop, like for example the trimming option were different between scRNAaseq and other workflows

from snakepipes.

the slight differing trimming option was intentionally, as poly-A trimming is "easier" with cutadapt, therefore scRNA-seq supports only cutadapt right now....but I can change this for consistency

from snakepipes.

@steffenheyne feel free to close this if you think it's done

from snakepipes.

Isn't cutadapt the default trimmer in the other workflows already? I wouldn't oppose getting rid of Trim Galore all together, since cutadapt is vastly faster.

from snakepipes.

yes, cutadapt is default everywhere...and as trimgalore is just a "convenience" wrapper around cutadapt, I'm fine getting rid of trimgalore.

more general aspect: I'm just always a bit afraid that we miss/might use the right adapter/primer sequence as there are eg slight diff. between small RNA-seq and other protocols, here trimGalore has some autodetect function, but also I'm not sure how good this is actually working etc...

should we make adapter sequence configureable via defaults.yaml?

from snakepipes.

currently we just use always "AGATCGGAAGAGC"

from snakepipes.

We could make that configurable I suppose. I actually want to add a --detect option to cutadapt (I looked into making Trim Galore multithreading...but that'd be absurdly complicated). I think Trim Galore does an OK job for the most part with adapter detection, but of course if you know what the adapter is then that'll always be the most reliable. The WGBS pipeline has two different adapter sequences built in, so one can instead trim with Nextera adapters if needed. Maybe that's the way to go, since we don't currently support sRNA-seq.

from snakepipes.

Yah if cutadapt rule can be adopted for multiple adaptor types, I would also vote to get rid of trim-galore

from snakepipes.

see now here
#151

from snakepipes.