<@U0938586SPK> So let's keep the QC Subworkflow on...
# sarek_dev
m
@Agrima Bhatt So let's keep the QC Subworkflow on the side for now, I will continue to write down ideas there. I think you can start on: • bam_applybqsr • bam_baserecalibrator • bam_markduplicates @Rike Hanssen regarding that, do we want to keep spark or not?
👍 1
I do think the input for these subworkflow can be further simplified, if we rewrite the input to be: cram, intervals, references we might need to touch the underlying modules for that
I do think we can try to ditch the bam_merge_index_samtools and cram_merge_index_samtools, and just replace with samtools_merge with -write-index
r
didn't we do this already?
Do we want to keep spark?
r
hm must have been in a different pipeline
m
If so, maybe we could merge the spark and non spark subworkflows
m
Hot take, are the spark workflows actually used by somewhere? Because those modules are the flakiest I’ve ever seen
m
ok, so let's drop support for it in sarek then?
r
If so, maybe we could merge the spark and non spark subworkflows
no, because they need slightly different upstream processing
👍 1
Hot take, are the spark workflows actually used by somewhere? Because those modules are the flakiest I’ve ever seen
unsure we have had a few bug reports soooooo maybe?
m
😐
m
the spark stuff is a PITA to update in #CJRH30T6V
r
maybe we can deprecate it and just not update it anymore and print a warning? If people start complaining we know someone is using it?