Strelka2's --callRegions option

[maotian06]

Hi @uclahs-cds/nextflow-wg
I have few questions that might be related to the Pyflow and nextflow:
Related to #70

---

I added a --callRegions option to the Strelka2 algorithm, which will only include the canonical sequencing. The runtime reduced, but when I checked the trace.txt, I found the %cpu was really low. You can see the comparison of strelka2 process W/O callRegions here:

callRegions	name	duration	realtime	%cpu	peak_rss	peak_vmem	rchar	wchar
with callRegions	strelka2:call_sSNV_Strelka2	47m 23s	47m 7s	2985.3%	4.3 GB	7.3 GB	261.7 GB	111.7 MB
without callRegions	strelka2:call_sSNV_Strelka2	1d 15h 57m 5s	1d 15h 56m 52s	163.9%	4.7 GB	7.7 GB	313.9 GB	178.7 MB

Q1: Any idea why the %CPU is low? Is that the average CPU usage?

---

Although excluding the non-canonical region can increase the efficiency, we still want to have the non-canonical sequence in the Strelka2, so I was wondering how we could improve strelka2's efficiency in the non-canonical sequence.

As far as I know, Strelka2 used Pyflow to parallelize the execution.
Here is the strelka2's code in call-sSNV pipeline:

pipeline-call-sSNV/pipeline/modules/strelka2-processes.nf

Line 89 in a2c580a

StrelkaSomaticWorkflow/runWorkflow.py -m local -j ${task.cpus}

Q2: Any idea how we could improve the running efficiency?

[yashpatel6]

For the efficiency with non-canonical regions, it seems like an issue with the tool itself: https://github.com/Illumina/strelka/blob/v2.9.x/docs/userGuide/README.md#improving-runtime-for-references-with-many-short-contigs-such-as-grch38

For both germline and somatic analysis, Strelka may have runtime issues while attempting to process the large number of small decoys and unplaced/unlocalized contigs found in GRCh38 and other reference genomes. This is due to a known issue with read realignment sporadically experiencing substantial slowdowns on very short, high-depth contigs. Until this issue can be resolved, runtime can be improved for such cases by excluding smaller contigs from analysis.

Until they address the issue, it doesn't seem like we can really improve runtime for the non-canonical regions. They claim the issue is sporadic so it's unlikely that something like increasing resources would help.