Move run specific parameters from samples.tsv to rule_config.yaml

The current layout of ZARP requires several parameters to be specified in the samples.tsv file, that should rather be specified in the recently introduced rule_config.yaml as they apply to all samples of a run.

Necessary changes in

• Snakefile, single/paired-end Snakefile
• rule_config.yaml
• samples.tsv, and consequently ZARP-cli. Corresponding issue here

Suggestions from #155 (closed) :
single_end.snakefile.smk and paired_end.snakefile.smk:

• map_genome_star: -- twopassMode
• map_genome_star: --alignEndsType

mentioned in merge request !83 (merged)

added Doing label

assigned to @katsanto

#160 (closed)

Restructuring features in the samples.tsv:

• Features discussed in #160 (closed)
• softclip
• passmode
• multimappers

I am thinking of keeping the --twopassMode basic option in the mapping instead of the None as default behaviour https://github.com/alexdobin/STAR/blob/master/doc/STARmanual.pdf. More reads will be mapped this way. What do you think @zavolan @kanitz ? If we decide to keep the default behaviour I will just eliminate it altogether.

The same holds for the multimappers outFilterMultimapNmax . I would keep those options in the rule config as they are the most commonly changed and keep the default values.

Maximum fragment length calculation issue within snakemake. Wire this in a per sample context.

For salmon Kmer keep the default value. -Leave it in the sample table Per sample inference. Aggregation step where we keep the maximum value. If there is an index path, then drop altogether.

mentioned in commit 2a934740

marked the checklist item Snakefile, single/paired-end Snakefile as completed

marked the checklist item rule_config.yaml as completed

Regarding the features index_size and kmer

• index_size : the idea was to have an aggregation rule that would process the reads and keep the maximum value
• kmer : keep the default value for now

Do we implement this in the ZARP-cli or do we have a rule that does it in the snakefile? I would be against the latter, as this means we would need a python script to infer the lengths and then some way to access the value from this rule as a parameter for the other rules. I think it is best that we keep those parameters in the samples table and infer them in the zarp-cli. What do you think? @zavolan @kanitz @gypas @herrmchr @burri0000 @bakma ?

I agree with you, I think generally, the less custom artificial rules (reformat this, infer that) you add to your workflow the better. We should delegate that functionality "outside" of the pipeline itself, I think that would be cleaner...
But this is not a strong opinion, just my feeling.

I agree with both, we should keep the two parameters in the sample table.

zarp-cli is intended to infer parameters such as those (at least this is my understanding of it).

marked the checklist item samples.tsv, and consequently ZARP-cli. Corresponding issue here as completed

mentioned in merge request !98 (merged)

Fixed in !98 (merged)

closed