vari-bbc / rnaseq_workflow Goto Github PK

optimize the resources allocated to STAR on HPC3 (120gb, 8ppn) to enable multiple jobs on a single node.

Would be nice to print the GO.XX tables that go into the clusterprofiler functions.
Would also be nice to toggle enrichment between up/down genes.
just some thoughts

Here is an example rule from the Snakemake manual (https://snakemake.readthedocs.io/en/stable/project_info/faq.html) that does essentially the same thing:

rule merge_files:
    output: "{foo}/all_merged.txt"
    input: my_input_func  # some function that yields 1 or more files to merge
    run:
        if len(input) > 1:
            shell("cat {input} | sort > {output}")
        else:
            shell("ln -sr {input} {output}")

Might be advantageous to automate the STAR index building so this is also hands-off.

• swap out conda: and/or singularity: for envmodules: directive within each rule.
• deprecate the use of wrappers in favor of shell: directive. makes processes much easier to read and understand.

enable user to provide PE or SE reads in units.tsv by simply including or omitting fq2

need to incorporate the config.yaml species information into the .Rmd so it will download the correct mart for annotation ens2gene, etc.

original workflow included DE test of all genes followed by filtering for FDR <0.05 and LogFC>1.5. This means FDR takes all genes into account -> even though we are only interested only in LogFC >1.5, FDR accounts for genes with logFC<1.5, so we are unnecessarily punished for these tests of genes that we already assume have no biological relevance.

Specify memory and threads in the rules themselves. This is easier to read and makes it more convenient to add new rules.

mergeLanesAndRename.R, accounts for projects where samples were sequenced across lanes by running cat on them. However, the majority of our projects are 1 file to 1 sample so a simple renaming using ln -s samplename.fastq.gz samplename-SE.fastq.gz would suffice to make the pipeline work if we test first to see if there is only one file per sample.

We could consider also running cat at the trim_galore step: trim_galore <(cat lane1_R1 lane2_R1 lane3_R1) <(cat lane1_R2 lane2_R2 lane3_R2). This is a bigger change to the pipeline and may require more debugging but would do away with the file copying even when the data are split across lanes.

I can work on this the next time I use this pipeline, but other people can feel free to tackle this if you are interested.

Log the version of each program that is actually implemented in the workflow. This information is useful for analyst reference.

Possible documentation locations:

• logs/
• within the diffExp.Rmd/.html report.
• elsewhere?